Project Management & Agile Mindset

Copyright © 2002 Poppendieck.LLC Page 1

Principles of Lean Thinking

Mary Poppendieck
Poppendieck.LLC

7666 Carnelian Lane
Eden Prairie, MN 55346 USA

952-934-7998
[email protected]

Abstract

In the 1980’s, a massive paradigm shift hit factories
throughout the US and Europe. Mass production and
scientific management techniques from the early 1900’s
were questioned as Japanese manufacturing companies
demonstrated that ‘Just-in-Time’ was a better paradigm.
The widely adopted Japanese manufacturing concepts
came to be known as ‘lean production’. In time, the
abstractions behind lean production spread to logistics,
and from there to the military, to construction, and to
the service industry. As it turns out, principles of lean
thinking are universal and have been applied
successfully across many disciplines.

Lean principles have proven not only to be universal,
but to be universally successful at improving results.
When appropriately applied, lean thinking is a well-
understood and well-tested platform upon which to
build agile software development practices.

Introduction

Call a doctor for a routine appointment and chances are
it will be scheduled a few weeks later. But one large
HMO in Minnesota schedules almost all patients within
a day or two of their call, for just about any kind of
medical service. A while ago, this HMO decided to
worked off their schedule backlogs by extending their
hours, and then vary their hours slightly from week to
week to keep the backlog to about a day. True, the
doctors don’t have the comforting weeks-long list of
scheduled patients, but in fact, they see just as many
patients for the same reasons as they did before. The
patients are much happier, and doctors detect medical
problems far earlier than they used to.

The idea of delivering packages overnight was novel
when Federal Express was started in 1971. In 1983, a
new company called Lens Crafters changed the basis of
competition in the eyeglasses industry by assembling
prescription glasses in an hour. The concept of

shipping products the same day they were ordered was
a breakthrough concept when LL Bean upgraded its
distribution system in the late 1980’s. Southwest
Airlines, one of the few profitable airlines these days,
saves a lot of money with its unorthodox method of
assigning seats as people arrive at the airport. Dell
maintains profitability in a cutthroat market by
manufacturing to order in less than a week. Another
Austin company builds custom homes in 30 days.

The common denominator behind these and many other
industry-rattling success stories is lean thinking. Lean
thinking looks at the value chain and asks: How can
things be structured so that the enterprise does nothing
but add value, and does that as rapidly as possible? All
the intermediate steps, all the intermediate time and all
the intermediate people are eliminated. All that’s left
are the time, the people and the activities that add value
for the customer.

Origins of Lean Thinking
Lean thinking got its name from a 1990’s best seller
called The Machine That Changed the World : The
Story of Lean Production1. This book chronicles the
movement of automobile manufacturing from craft
production to mass production to lean production. It
tells the story of how Henry Ford standardized
automobile parts and assembly techniques, so that low
skilled workers and specialized machines could make
cheap cars for the masses. The book goes on to
describe how mass production provided cheaper cars
than the craft production, but resulted an explosion of
indirect labor: production planning, engineering, and
management. Then the book explains how a small
company set its sights set on manufacturing cars for
Japan, but it could not afford the enormous investment
in single purpose machines that seemed to be required.

1 The Machine That Changed the World : The Story of Lean
Production, by Womack, James P., Daniel T. Jones, and
Daniel Roos, New York: Rawson and Associates; 1990.

Copyright © 2002 Poppendieck.LLC Page 2

Nor could it afford the inventory or large amount of
indirect labor that seemed necessary for mass
production. So it invented a better way to do things,
using very low inventory and moving decision-making
to production workers. Now this small company has
grown into a large company, and the Toyota Production
System has become known as ‘lean production’.

“The mass-producer uses narrowly skilled professionals
to design products make by unskilled or semiskilled
workers tending expensive, single-purpose machines.
These churn out standardized products at high volume.
Because the machinery costs so much and is so
intolerant of disruption, the mass-producer adds many
buffers – extra supplies, extra workers, and extra space
– to assure smooth production…. The result: The
customer gets lower costs but at the expense of variety
and by means of work methods that most employees
find boring and dispiriting.”2

Think of the centralized eyeglasses laboratory.
Remember that Sears used to take two or three weeks to
fill orders from its once-popular catalog. Recall the
long distribution channel that used to be standard in the
computer market. Think dinosaurs. Centralized
equipment, huge distribution centers and lengthy
distribution channels were created to realize economies
of scale. They are the side effects of mass-production,
passed on to other industries. What people tend to
overlook is that mass-production creates a tremendous
amount of work that does not directly add value.
Shipping eyeglasses to a factory for one hour of
processing adds more handling time by far than the
processing time to make the glasses. Adding retail
distribution to the cutthroat personal computer industry
means that a manufacturer needs six weeks to respond
to changing technology, instead of six days. Sears’
practice of building an inventory of mail orders to fill
meant keeping track of stacks of orders, not to mention
responding to innumerable order status queries and
constant order changes.

“The lean producer, by contrast, combines the
advantages of craft and mass production, while
avoiding the high cost of the former and the rigidity of
the later… Lean production is ‘lean’ because it uses
less of everything compared with mass production –
half the human effort in the factory, half the
manufacturing space, half the investment in tools, half
the engineering hours to develop a new product in half
the time. Also, it requires keeping far less than half the
inventory on site, results in many fewer defects, and

2 Womack (1990) p 13.

produces a greater and ever growing variety of
products.”3

While on a tour of a large customer, Michael Dell saw
technicians customizing new Dell computers with their
company’s ‘standard’ hardware and software. “Do you
think you guys could do this for me?” his host asked.
Without missing a beat, Dell replied, “Absolutely, we’d
love to do that.”4 Within a couple of weeks, Dell was
shipping computers with factory-installed, customer-
specific hardware and software. What took the
customer an hour could be done in the factory in
minutes, and furthermore, computers could be shipped
directly to end-users rather than making a stop in the
corporate IT department. This shortening of the value
chain is the essence of lean thinking.

Companies that re-think the value chain and find ways
to provide what their customers value with significantly
fewer resources than their competitors can develop an
unassailable competitive advantage. Sometimes
competitors are simply not able to deliver the new value
proposition. (Many have tired to copy Dell; few have
succeeded.) Sometimes competitors do not care to
copy a new concept. (Southwest Airlines has not
changed the industry’s approach to seat assignments.)
Sometimes the industry follows the leader, but it takes
time. (Almost all direct merchandise is shipped within a
day or two of receiving an order these days, but the
Sears catalog has been discontinued.)

Lean Thinking in Software Development
eBay is a company which pretty much invented ‘lean’
trading by eliminating all the unnecessary steps in the
trading value chain. In the mid 1990’s, basic eBay
software capabilities were developed by responding
daily to customer requests for improvements.5
Customers would send an e-mail to Pierre Omidyar
with a suggestion and he would implement the idea on
the site that night. The most popular features of eBay,
those which create the highest competitive advantage,
were created in this manner.

Digital River invented the software download market in
the mid 1990’s by focusing on ‘lean’ software delivery.
Today Digital River routinely designs and deploys

3 Womack (1990) p 13.
4 Direct from Dell, by Michael Dell with Catherine Fredman,
Harper Business, 1999, p 159
5 Q&A with eBay’s Pierre Omidyar, Business Week Online,
December 3, 2001.

Copyright © 2002 Poppendieck.LLC Page 3

sophisticated web sites for corporate customers in a
matter of a weeks, by tying the corporation’s legacy
databases to standard front end components customized
with a ‘look and feel’ specific to each customer.

In the mid 1990’s, Microsoft implemented corporate-
wide financial, purchasing and human resource
packages linked to data warehouses which can be
accessed via web front-ends. Each was implemented
by “a handful of seasoned IT and functional experts…
(who got) the job done in the time it takes a …
committee to decide on its goals.”6

In each of these examples, the focus of software
development was on rapid response to an identified
need. Mechanisms were put in place to dramatically
shorten the time from problem recognition to software
solution. You might call it ‘Just-in-Time’ software
development.

The question is – why isn’t all software developed
quickly? The answer is – rapid development must be
considered important before it becomes a reality. Once
speed becomes a value, a paradigm shift has to take
place, changing software development practices from
the mass production paradigm to lean thinking.

If your company writes reams of requirements
documents (equivalent to inventory), spends hours upon
hours tracking change control (equivalent to order
tracking), and has an office which defines and monitors
the software development process (equivalent to
industrial engineering), you are operating with mass-
production paradigms. Think ‘lean’ and you will find a
better way.

Basic Principles of Lean Development

There are four basic principles of lean thinking which
are most relevant to software development:

The Basic Principles of Lean Development
Add Nothing But Value (Eliminate Waste)
Center On The People Who Add Value

Flow Value From Demand (Delay Commitment)
Optimize Across Organizations

6 Inside Microsoft: Balancing Creativity and Discipline,
Herbold, Robert J.; Harvard Business Review, January 2002.

Add Nothing But Value (Eliminate Waste)
The first step in lean thinking is to understand what
value is and what activities and resources are absolutely
necessary to create that value. Once this is understood,
everything else is waste. Since no one wants to
consider what they do as waste, the job of determining
what value is and what adds value is something that
needs to be done at a fairly high level. Let’s say you
are developing order tracking software. It seems like it
would be very important for a customer to know the
status of their order, so this would certainly add
customer value. But actually, if the order is in house
for less than 24 hours, the only order status that is
necessary is to inform the customer that the order was
received, and then that it has shipped, and let them
know the shipping tracking number. Better yet, if the
order can be fulfilled by downloading it on the Web,
there really isn’t any order status necessary at all.

To develop breakthroughs with lean thinking, the first
step is learning to see waste. If something does not
directly add value, it is waste. If there is a way to do
without it, it is waste. Taiichi Ohno, the mastermind of
the Toyota Production System, identified seven types of
manufacturing waste:

The Seven Wastes of Manufacturing
Overproduction

Inventory
Extra Processing Steps

Motion
Defects
Waiting

Transportation

Here is how I would translate the seven wastes of
manufacturing to software development:

The Seven Wastes of Software Development
Overproduction = Extra Features

Inventory = Requirements
Extra Processing Steps = Extra Steps

Motion = Finding Information
Defects = Defects Not Caught by Tests
Waiting = Waiting, Including Customers

Transportation = Handoffs

Copyright © 2002 Poppendieck.LLC Page 4

Extreme Programming (XP) is a set of practices which
focuses on rapid software development. It is interesting
to examine how XP works to eliminate the seven
wastes of software development:

Waste in Software
Development

How Extreme Programming
Addresses Waste

Extra Features Develop only for today’s
stories

Requirements Story cards are detailed only
for the current iteration

Extra Steps
Code directly from stories;
get verbal clarification directly
from customers

Finding Information Have everyone in the same
room; customer included

Defects Not
Caught by Tests

Test first; both developer
tests and customer tests

Waiting, Including
Customers Deliver in small increments

Handoffs Developers work directly with
customers

‘Do It Right The First Time’
XP advocates developing software for the current need,
and as more ‘stories’ (requirements) are added, the
design should be ‘refactored’7 to accommodate the new
stories. Is it waste to refactor software? Shouldn’t
developers “Do It Right the First Time?”

It is instructive to explore the origins of the slogan “Do
It Right the First Time.” In the 1980’s it was very
difficult to change a mass-production plant to lean
production, because in mass production, workers were
not expected to take responsibility for the quality of the
product. To change this, the management structure of
the plant had to change. “Workers respond only when
there exists some sense of reciprocal obligation, a sense
that management actually values skilled workers, …
and is willing to delegate responsibility to [them].”8
The slogan “Do It Right the First Time” encouraged
workers to feel responsible for the products moving
down the line, and encourage them to stop the line and
troubleshoot problems when and where they occurred.

7 Refactoring is improving the design of software without
changing functionality.
8 Womack (1990) p 99.

In the software industry, the same slogan “Do It Right
the First Time,” has been misused as an excuse to apply
mass-production thinking, not lean thinking to software
development. Under this slogan, responsibility has
been taken away from the developers who add value,
which is exactly the opposite of its intended effect.
“Do It Right the First Time” has been used as an excuse
to insert reams of paperwork and armies of analysts and
designers between the customer and the developer. In
fact, the slogan is only properly applied if it gives
developers more, not less, involvement in the results of
their work.

A more appropriate translation of such slogans as “Zero
Defects” and “Do It Right the First Time” would be
“Test First”. In other words, don’t code unless you
understand what the code is supposed to do and have a
way to determine whether the code works. A good
knowledge of the domain coupled with short build
cycles and automated testing constitute the proper way
for software developers to “Do It Right the First Time”.

Center On The People Who Add Value
Almost every organization claims it’s people are
important, but if they truly center on those who add
value, they would be able to say:

The people doing the work are the center of
Resources
Information

Process Design Authority
Decision Making Authority

Organizational Energy

In mass-production, tasks are structured so that low
skilled or unskilled workers can easily do the repetitive
work, but engineers and managers are responsible for
production. Workers are not allowed to modify or stop
the line, because the focus is to maintain volume. One
of the results of mass-production is that unskilled
workers have no incentive to volunteer information
about problems with the manufacturing line or ways to
improve the process. Maladjusted parts get fixed at the
end of the line; a poor die or improperly maintained
tool is management’s problem. Workers are neither
trained nor encouraged to worry about such things.

“The truly lean plant has two key organizational
features: It transfers the maximum number of tasks and
responsibilities to those workers actually adding value
to the car on the line, and it has in place a system for

Copyright © 2002 Poppendieck.LLC Page 5

detecting defects that quickly traces every problem,
once discovered, to its ultimate cause.”9 Similarly in
any lean enterprise, the focus is on the people who add
value. In lean enterprises, traditional organizational
structures give way to new team-oriented organizations
which are centered on the flow of value, not on
functional expertise.

The first experiment Taiichi Ohno undertook in
developing lean production was to figure out a way to
allow massive, single-purpose stamping machines to
stamp out multiple parts. Formerly, it took skilled
machinists hours, if not days, to change dies from one
part to another. Therefore, mass production plants had
many single purpose stamping machines in which the
dies were almost never changed. Volume, space, and
financing were not available in Japan to support such
massive machines, so Ohno set about devising simple
methods to change the stamping dies in minutes instead
of hours. This would allow many parts of a car to be
made on the same line with the same equipment. Since
the workers had nothing else to do while the die was
being changed, they also did the die changing, and in
fact, the stamping room workers were involved in
developing the methods of rapid die changeover.

Ohno transferred most of the work being done by
engineers and managers in mass-production plants to
the production workers. He grouped workers in small
teams and trained the teams to do their own industrial
engineering. Workers were encouraged to stop the line
if anything went wrong, (a management job in mass-
production). Before the line was re-started, the workers
were expected to search for the root cause of the
problem and resolve it. At first the line was stopped
often, which would have been a disaster at a mass-
production plant. But eventually the line ran with very
few problems, because the assembly workers felt
responsible to find, expose, and resolve problems as
they occurred.

It is sometimes thought that a benefit of good software
engineering is to allow low skilled programmers to
produce code while a few high skilled architects and
designers do the critical thinking. With this in mind, a
project is often divided into requirements gathering,
analysis, design, coding, testing, and so on, with
decreasing skill presumably required at each step. A
‘standard process’ is developed for each step, so that
low-skilled programmers, for example, can translate
design into code simply by following the process.

9 Womack (1990) p 99. Italics in the original.

This kind of thinking comes from mass-production,
where skilled industrial engineers are expected to
design production work for unskilled laborers. It is the
antithesis of lean thinking and devalues the skills of the
developers who actually write the code as surely as
industrial engineers telling laborers how to do their jobs
devalues the skills of production workers.

Centering on the people who add value means
upgrading the skills of developers through training and
apprenticeships. It means forming teams that design
their own processes and address complete problems. It
means that staff groups and managers exist to support
developers, not to tell them what to do.

Flow Value From Demand
(Delay Commitment)

The idea of flow is fundamental to lean production. If
you do nothing but add value, then you should add the
value in as rapid a flow as possible. If this is not the
case, then waste builds up in the form of inventory or
transportation or extra steps or wasted motion. The
idea that flow should be ‘pulled’ from demand is also
fundamental to lean production. ‘Pull’ means that
nothing is done unless and until a downstream process
requires it. The effect of ‘pull’ is that production is not
based on forecast; commitment is delayed until demand
is present to indicate what the customer really wants.

Pulling from demand can be one of the easiest ways to
implement lean principles, as LL Bean and Lens
Crafters and Dell found out. The idea is to fill each
customer order immediately. In mass-production days,
filling orders immediately meant building up lots of
inventory in anticipation of customer orders. Lean
production changes that. The idea is to be able to make
the product so fast that it can be made to order. True,
Dell and Lens Crafters and LL Bean and Toyota have to
have some inventory of sub-assemblies waiting to be
turned into a finished product at a moments notice.
But it’s amazing how little inventory is necessary, if the
process to replenish the inventory is also lean. A truly
lean distribution channel only works with a really lean
supply chain coupled to very lean manufacturing.

The “batch and queue” habit is very hard to break. It
seems counterintuitive that doing a little bit at a time at
the last possible moment will give faster, better,
cheaper results. But anyone designing a control system
knows that a short feedback loop is far more effective at
maintaining control of a process than a long loop. The
problem with batches and queues is that they hide
problems. The idea of lean production is to expose

Copyright © 2002 Poppendieck.LLC Page 6

problems as soon as they arise, so they can be corrected
immediately. It may seem that lean systems are fragile,
because they have no padding. But in fact, lean
systems are quite robust, because they don’t hide
unknown, lurking problems and they don’t pretend they
can forecast the future.

In Lean Software Development, the idea is to maximize
the flow of information and delivered value. As in lean
production, maximizing flow does not mean
automation. Instead, it means limiting what has to be
transferred, and transferring that as few times as
possible over the shortest distance with the widest
communication bandwidth as late as is possible.
Handing off reams of frozen documentation from one
function to the next is a mass-production mentality. In
Lean Software Development, the idea is to eliminate as
many documents and handoffs as possible. Documents
which are not useful to the customer are replaced with
automated tests. These tests assure that customer value
is delivered both initially and in the future when the
inevitable changes are needed.

In addition to rapid, Just-in-Time information flow,
Lean Software Development means rapid, Just-in-Time
delivery of value. In manufacturing, the key to
achieving rapid delivery is to manufacture in small
batches pulled by a customer order. Similarly in
software development, the key to rapid delivery is to
divide the problem into small batches (increments)
pulled by a customer story and customer test. The
single most effective mechanism for implementing lean
production is adopting Just-in-Time, pull-from-demand
flow. Similarly, the single most effective mechanism
for implementing Lean Development is delivering
increments of real business value in short time-boxes.

In Lean Software Development, the goal is to eliminate
as many documents and handoffs as possible. The
emphasis is to pair a skilled development team with a
skilled customer team and give them the responsibility
and authority to develop the system in small, rapid
increments, driven by customer priority and feedback.

Optimize across Organizations
Quite often, the biggest barrier to adopting lean
practices is organizational. As products move from one
department to another, a big gap often develops,
especially if each department has its own set of
performance measurements that are unrelated to the
performance measurements of neighboring
departments.

For example, let’s say that the ultimate performance
measurement of a stamping room is machine
productivity. This measurement motivates the
stamping room to build up mounds of inventory to keep
the machines running at top productivity. It does not
matter that the inventory has been shown to degrade the
overall performance of the organization. As long as the
stamping room is measured primarily on machine
productivity, it will build inventory. This is what is
known as a sub-optimizing measurement, because it
creates behavior which creates local optimization at the
expense of overall optimization.

Sub-optimizing measurements are very common, and
overall optimization is virtually impossible when they
are in place. One of the biggest sub-optimizing
measurements in software development occurs when
project managers are measured on earned value.
Earned value is the cost initially estimated for the tasks
which have been completed. The idea is that you had
better not have spent any more than you estimated. The
problem is, this requires a project manager to build up
an inventory of task descriptions and estimates. Just as
excess inventory in the stamping room slows down
production and degrades over time, the inventory of
tasks required for earned value calculations gets in the
way of delivering true business value and also degrades
over time. Nevertheless, if there is an earned value
measurement in place, project tasks are specified and
estimated, and earned value is measured. When it
comes to a choice between delivering business value or
earned value (and it often does), earned value usually
wins out.

To avoid these problems, lean organizations are
usually structured around teams that maintain
responsibility for overall business value, rather than
intermediate measurements such as their ability to
speculate and pad estimates. Another approach is to
foster a keen awareness that the downstream
department is a customer, and satisfying this internal
customer is the ultimate performance measurement.

The paradigm shift that is required with lean thinking is
often hindered if the organization is not structured
around the flow of value and focused on helping the
customer pull value from the enterprise. For this
reason, software development teams are best structured
around delivering increments of business value, with all
the necessary skills on the same team (eg. customer
understanding / domain knowledge, architecture /
design, system development, database administration,
testing, system administration, etc.).

Copyright © 2002 Poppendieck.LLC Page 7

Software Development Contracts
Flow along the value stream is particularly difficult
when multiple companies are involved. Many times I
have heard the lament: “Everything you say makes
sense, but it is impossible to implement in our
environment, because we work under contracts with
other organizations.” Indeed, the typical software
development contract can be the ultimate sub-
optimizing mechanism. Standard software contracts
and supplier management practices have a tendency to
interfere with many lean principles.

Manufacturing organizations used to have the same
problem. For example, US automotive companies once
believed the best way to reduce the cost of parts in an
automobile was with annual competitive bidding. If the
only thing that is important is cheap parts, competitive
bidding may seem like the best way to achieve this
goal. However, if overall company performance is
more important, then better parts which integrate more
effectively with the overall vehicle are more valuable.
In fact, there is an direct correlation between an
automotive company’s profitability and its degree of
collaboration with suppliers.10 When Chrysler moved
from opportunistic to collaborative relationships with
its suppliers in the late 1990’s, it’s performance
improved significantly.

The software industry has some lessons to learn in the
area of contractual agreements between organizations.
It needs to learn how to structure collaborative
relationships which maximize the overall results of both
parties. A key lesson the software industry needs to
learn is how to structure contracts for incremental
deliveries that are not pre-defined in the contract, yet
assure the customer of prompt delivery of business
value appropriate to their investment. Here again, we
can learn from lean production.

Lean manufacturing organizations develop a limited
number of relationships with ‘trusted’ suppliers, and in
turn, gain the ‘trust’ of these suppliers. What does
‘trust’ mean? “Trust [is] one party’s confidence that
the other party in the exchange relationship will fulfill
its promises and commitments and will not exploit its
vulnerabilities.”11 “…trust…[is] not based on greater
interpersonal trust, but rather greater trust in the

10 Collaborative Advantage, by Jeffrey H. Dyer, Oxford
University Press; 2000, p 6.
11 Dyer (2000) p 88.

fairness, stability, and predictability of [the company’s]
routines and processes.”12

It has been the practice of legal departments writing
software contracts to put into contractual language all
of the protections necessary to keep the other side
‘honest.’ However, the transaction costs associated
with creating and monitoring such contracts are
enormous. Many contracts all but demand a waterfall
process, even if both companies believe this is not the
best approach. It’s time that the software development
industry learned the lesson of Supply Chain
Management – “Extraordinary productivity gains in the
production network or value chain are possible when
companies are willing to collaborate in unique ways,
often achieving competitive advantage by sharing
resources, knowledge, and assets…. Today
competition occurs between value chains and not
simply between companies.”13

Summary and Conclusion
The lean production metaphor is a good one for
software development, if it is applied in keeping with
the underlying spirit of lean thinking. In the past, the
application of some manufacturing concepts to software
development (‘Do It Right the First Time’ comes to
mind) may have lacked a deep understanding of what
makes lean principles work. The underlying principles
of eliminating waste, empowering front line workers,
responding immediately to customer requests, and
optimizing across the value chain are fundamental to
lean thinking. When applied to software development,
these concepts provide a broad framework for
improving software development.

12 Dyer (2000) p 100
13 Dyer (2000) p 5

Figure 1. The evolution of the Waterfall Model (a) and its long development cycles (analysis, design, implementation, test) to the shorter, iterative devel-
opment cycles within, for example, the Spiral Model (b) to Extreme Programming’s (c) blending of all these activities, a little at a time, throughout the
entire software development process.

0018-9162/99/$10.00 © 1999 IEEE70 Computer

I
n the beginning was the waterfall (Figure 1a). We
would get the users to tell us once and for all
exactly what they wanted. We would design the
system that would deliver those features. We
would code it. We would test to make sure the

features were delivered. All would be well.
All was not well. The users didn’t tell us once and

for all exactly what they wanted. They didn’t know.
They contradicted themselves. They changed their
minds. And the users weren’t the only problem. We
programmers could think we were making great
progress only to discover three-fourths of the way
through that we were one-third of the way through.

If long development cycles were bad because they
couldn’t adapt to changes, perhaps what we needed
was to make shorter development cycles. As Figure 1b

shows, the waterfall begat iterations.
The waterfall model didn’t just appear. It was a

rational reaction to the shocking measurement that
the cost of changing a piece of software rose dramat-
ically over time. If that’s true, then you want to make
the biggest, most far-reaching decisions as early in the
life cycle as possible to avoid paying big bucks for
them.

The academic software engineering community
took the high cost of changing software as a challenge,
creating technologies like relational databases, mod-
ular programming, and information hiding. What if
all that hard work paid off? What if we got good at
reducing the costs of ongoing changes? What if we
didn’t have to settle for taking a cleaver to the water-
fall? What if we could throw it in a blender?

Extreme Programming turns the conventional software process sideways.
Rather than planning, analyzing, and designing for the far-flung future, XP
programmers do all of these activities—a little at a time—throughout
development.

Cover Feature

Embracing
Change with
Extreme
Programming

Kent Beck
First Class
Software

Co
ve

r F
ea

tu
re

Analysis

Design

Implementation

Test

Time

Scope

IterativeWaterfall XP

(c)(b)(a)

October 1999 71

We might get a picture like the one shown in Figure
1c. It’s called Extreme Programming.

ANATOMY OF XP
XP turns the conventional software process side-

ways. Rather than planning, analyzing, and design-
ing for the far-flung future, XP exploits the reduction
in the cost of changing software to do all of these
activities a little at a time, throughout software devel-
opment. (The “XP Practices” sidebar will give you a
quick grasp of the practices and philosophy underly-
ing XP. These practices are designed to work together,
and trying to examine any one soon leads you to the
rest. The “Roots of XP” sidebar on page 73 traces the
historical antecedents of these practices.)

XP development cycle
Figure 2 shows XP at timescales ranging from years

to days. The customer picks the next release by choos-
ing the most valuable features (called stories in XP)
from among all the possible stories, as informed by
the costs of the stories and the measured speed of the
team in implementing stories.

The customer picks the next iteration’s stories by
choosing the most valuable stories remaining in the
release, again informed by the costs of the stories and
the team’s speed. The programmers turn the stories
into smaller-grained tasks, which they individually

XP Practices

Here is a quick summary of each of the
major practices in XP.

Planning game. Customers decide the
scope and timing of releases based
on estimates provided by program-
mers. Programmers implement only
the functionality demanded by the
stories in this iteration.

Small releases. The system is put into
production in a few months, before
solving the whole problem. New
releases are made often—anywhere
from daily to monthly.

Metaphor. The shape of the system is
defined by a metaphor or set of
metaphors shared between the cus-
tomer and programmers.

Simple design. At every moment, the
design runs all the tests, communi-
cates everything the programmers
want to communicate, contains no

duplicate code, and has the fewest
possible classes and methods. This
rule can be summarized as, “Say
everything once and only once.”

Tests. Programmers write unit tests
minute by minute. These tests are col-
lected and they must all run correctly.
Customers write functional tests for
the stories in an iteration. These tests
should also all run, although practi-
cally speaking, sometimes a business
decision must be made comparing the
cost of shipping a known defect and
the cost of delay.

Refactoring. The design of the system
is evolved through transformations
of the existing design that keep all
the tests running.

Pair programming. All production
code is written by two people at one
screen/keyboard/mouse.

Continuous integration. New code is
integrated with the current system
after no more than a few hours.

When integrating, the system is built
from scratch and all tests must pass
or the changes are discarded.

Collective ownership. Every program-
mer improves any code anywhere in
the system at any time if they see the
opportunity.

On-site customer. A customer sits with
the team full-time.

40-hour weeks. No one can work a
second consecutive week of over-
time. Even isolated overtime used
too frequently is a sign of deeper
problems that must be addressed.

Open workspace. The team works in a
large room with small cubicles around
the periphery. Pair programmers work
on computers set up in the center.

Just rules. By being part of an Extreme
team, you sign up to follow the rules.
But they’re just the rules. The team
can change the rules at any time as
long as they agree on how they will
assess the effects of the change.

accept responsibility for.
Then the programmer turns a task into a set of test

cases that will demonstrate that the task is finished.
Working with a partner, the programmer makes the
test cases run, evolving the design in the meantime to
maintain the simplest possible design for the system
as a whole.

Stories
XP considers the period before a system first goes

into production to be a dangerous anomaly in the life
of the project and to be gotten over as quickly as pos-
sible. However, every project has to start somewhere.

The first decisions to make about the project are
what it could do and what it should do first. These deci-
sions are typically the province of analysis, hence the
thin blue analysis rectangle at the top of Figure 1c. You
can’t program until you know what you’re program-
ming.

You put the overall analysis together in terms of
stories, which you can think of as the amount of a use
case that will fit on an index card. Each story must be
business-oriented, testable, and estimable.

A month is a good long time to come up with the
stories for a 10 person-year project. It’s true that it
isn’t enough to explore all of the possible issues thor-
oughly. But forever isn’t long enough to explore all of
the issues thoroughly if you never implement.

72 Computer

Release
Notice in Figure 2 that we don’t implement all of

the stories at first. Instead, the customer chooses the
smallest set of the most valuable stories that make sense
together. First we implement those and put them into
production. After that we’ll implement all the rest.

Picking the scope for a release is a little like shop-
ping for groceries. You go to the store with $100 in
your pocket. You think about your priorities. You look
at the prices on the items. You decide what to buy.

In the planning game (the XP planning process), the
items are the stories. The prices are the estimates on
the stories. The budget is calculated by measuring the
team’s output in terms of estimated stories delivered
per unit time.

The customer can either load up a cart (pick a set of
stories) and have the programmers calculate the finish
date or pick a date and have the programmers calcu-
late the budget, then choose stories until they add up.

Iteration
The goal of each iteration is to put into production

some new stories that are tested and ready to go. The
process starts with a plan that sets out the stories to be
implemented and breaks out how the team will
accomplish it. While the team is implementing, the
customer is specifying functional tests. At the end of
the iteration, the tests should run and the team should
be ready for the next iteration.

Iteration planning starts by again asking the cus-
tomer to pick the most valuable stories, this time out

of the stories remaining to be implemented in this
release. The team breaks the stories down into tasks,
units of implementation that one person could imple-
ment in a few days. If there are technical tasks, like
upgrading to a new version of a database, they get put
on the list too.

Next, programmers sign up for the tasks they want
to be responsible for implementing. After all the tasks
are spoken for, the programmer responsible for a task
estimates it, this time in ideal programming days.
Everyone’s task estimates are added up, and if some
programmers are over and some are under, the under-
committed programmers take more tasks.

Over the course of the iteration, the programmers
implement their tasks. As they complete each task, they
integrate its code and tests with the current system. All
tests must run or the code cannot be integrated.

As the customer delivers the functional tests dur-
ing the iteration, they are added to the suite. At the
end of the iteration, all unit tests and all functional
tests run.

Task
To implement a task, the responsible programmer

first finds a partner because all production code is writ-
ten with two people at one machine. If there is any
question about the scope or implementation approach,
the partners will have a short (15-minute) meeting with
the customer and/or with the programmers most
knowledgeable about the code most likely to be
touched during implementation.

Release

Years

Months

Weeks

Days

Iteration

Implementation

Stories

Tasks

Tests

Figure 2. XP according to various timescales. At the scale of months and years, you have the stories in this release and then
the stories in future releases. At the scale of weeks and months, you have stories in this iteration and then the stories remain-
ing in this release. At the scale of days and weeks, you have the task you are working on now and then the rest of the tasks in
the iteration. And at the scale of minutes and days, you have the test case you are working on now and then the rest of the test
cases that you can imagine.

From this meeting, the partners condense the list of
test cases that need to run before the task is done. They
pick a test case from the list that they are confident
they can implement and that will teach them some-
thing about the task. They code up the test case. If the
test case already runs, they go on. Normally, though,
there is work to be done.

When we have a test case and it doesn’t run, either

• we can see a clean way to make it run, in which
case we make it run; or

• we can see an ugly way to make it run, but we
can imagine a new design in which it could be
made to run cleanly, in which case we refactor
the system to make it run cleanly; or

• we can see an ugly way to make it run, but we
can’t imagine any refactoring, in which case we
make it run the ugly way.

After the test case runs, if we see how to refactor

the system to make it even cleaner, we do so.
Perhaps during the implementation of this test case

we imagine another test case that should also run. We
note the new test case on our list and continue.
Perhaps we spot a bigger refactoring that doesn’t fit
into the scope of our current test. We also note that
and continue. The goal is to remain focused so we can
do a good job and at the same time not lose the ben-
efits of the insights that come during intense interac-
tion with code.

Test
If there is a technique at the heart of XP, it is unit

testing. As you saw above, unit testing is part of
every programmer’s daily business. In XP, however,
two twists on conventional testing strategies make tests
far more effective: Programmers write their own tests
and they write these tests before they code. If pro-
gramming is about learning, and learning is about get-
ting lots of feedback as quickly as possible, then you

October 1999 73

Roots of XP

The individual practices in XP are not
by any means new. Many people have
come to similar conclusions about the
best way to deliver software in environ-
ments where requirements change vio-
lently.1-3

The strict split between business and
technical decision making in XP comes
from the work of the architect Christo-
pher Alexander, in particular his work
The Timeless Way of Building,4 where he
says that the people who occupy a struc-
ture should (in conjunction with a build-
ing professional) be the ones to make the
high-impact decisions about it.

XP’s rapid evolution of a plan in
response to business or technical changes
echoes the Scrum methodology5 and Ward
Cunningham’s Episodes pattern language.6

The emphasis on specifying and sched-
uling projects from the perspective of fea-
tures comes from Ivar Jacobson’s work
on use cases.7

Tom Gilb is the guru of evolutionary
delivery. His recent writings on EVO8

focus on getting the software into pro-
duction in a matter of weeks, then grow-
ing it from there.

Barry Boehm’s Spiral Model was the
initial response to the waterfall.9 Dave

Thomas and his colleagues at Object
Technology International have long been
champions of exploiting powerful tech-
nology with their JIT method.10

XP’s use of metaphors comes from
George Lakoff and Mark Johnson’s
books, the latest of which is Philosophy in
the Flesh.11 It also comes from Richard
Coyne, who links metaphor with soft-
ware development from the perspective
of postmodern philosophy.12

Finally, XP’s attitude toward the effects
of office space on programmers comes
from Jim Coplien,13 Tom DeMarco, and
Tim Lister,14 who talk about the impor-
tance of the physical environment on pro-
grammers.

References
1. J. Wood and D. Silver, Joint Application

Development, John Wiley & Sons, New
York, 1995.

2. J. Martin, Rapid Application Development,
Prentice Hall,Upper Saddle River, N.J.,1992.

3. J. Stapleton, Dynamic Systems Develop-
ment Method, Addison Wesley Longman,
Reading, Mass., 1997.

4. C. Alexander, The Timeless Way of Build-
ing, Oxford University Press, New York,
1979.

5. H. Takeuchi and I. Nonaka, “The New
Product Development Game,” Harvard

Business Rev., Jan./Feb. 1986, pp. 137-
146.

6. W. Cunningham, “Episodes: A Pattern
Language of Competitive Development,”
Pattern Languages of Program Design 2,
J. Vlissides, ed., Addison-Wesley, New
York, 1996.

7. I. Jacobsen, Object-Oriented Software
Engineering, Addison-Wesley, New York,
1994.

8. T. Gilb, Principles of Software Engineer-
ing Management, Addison-Wesley, Wok-
ingham, UK, 1988.

9. B. Boehm, “A Spiral Model of Software
Development and Enhancement,” Com-
puter, May 1988, pp. 61-72.

10. D. Thomas, “Web Time Software Devel-
opment,” Software Development, Oct.
1998, p. 80.

11. G. Lakoff and M. Johnson, Philosophy in
the Flesh, Basic Books, New York, 1998.

12. R. Coyne, Designing Information Tech-
nology in the Postmodern Age, MIT
Press, Cambridge, Mass., 1995.

13. J.O. Coplien, “A Generative Development
Process Pattern Language,” The Patterns
Handbook, L. Rising, ed., Cambridge Uni-
versity Press, New York, 1998, pp. 243-
300.

14. T. DeMarco and T. Lister, Peopleware,
Dorset House, New York, 1999.

74 Computer

can learn much from tests written by someone else days
or weeks after the code. XP primarily addresses the
accepted wisdom that programmers can’t possibly test
their own code by having you write code in pairs.

Some methodologies, like Cleanroom,1 prohibit
programmers testing or in some cases even com-
piling their own programs. The usual process has a
programmer write some code, compile it, make
sure it works, then pass it on to a testing organiza-
tion. The bench testing takes the form of single-
stepping through the code and watching variables,
or interpreting the results of print statements, or
poking a few buttons to make sure the list item
turns green.

The XP testing strategy doesn’t ask any more work
than the usual bench testing strategies. It just changes
the form of the tests. Instead of activities that evapo-
rate into the ether as soon as they are finished, you
record the tests in a permanent form. These tests will
run automatically today, and this afternoon after we
all integrate, and tomorrow, and next week, and next

year. The confidence they embody accumulates, so an
XP team gains confidence in the behavior of its sys-
tem over time.

As I mentioned earlier, tests also come from the cus-
tomers. At the beginning of an iteration, the customers
think about what would convince them that the sto-
ries for an iteration are completed. These thoughts are
converted into systemwide tests, either directly by the
customer using a textual or graphical scripting lan-
guage or by the programmers using their own testing
tools. These tests, too, accumulate confidence, but in
this case they accumulate the customer’s confidence
in the correct operation of the system.

WHEN SOMETHING GOES WRONG
Talking about how a method works when it works

perfectly is about like describing precisely how you
will descend a monstrous patch of white water. What
is interesting is precisely what you will do when the
unexpected or undesired happens. Here are some com-
mon failures and possible Extreme reactions.

Acxiom: Working
toward a Common Goal

Jim Hannula, Acxiom

On top of a data warehouse, Acxiom
built a campaign management applica-
tion using Forté’s distributed OO devel-
opment tool. The small development
team—consisting of 10 developers—built
the application by relying on sound OO
principles and a strong team development
approach.

During the final two years of the appli-
cation’s three years of development, the
team—comprised of managers, business
analysts, developers, testers, and techni-
cal writers—used Extreme Programming
techniques, which proved to be instru-
mental in our success.

We know we have a good design if it’s
simple. Some of our past designs tried
even to account for future iterations of
our application. We discovered that we
were not very good at that. If we use pat-
terns and communicate well, we can
develop a sound application that is flexi-
ble and can still be modified in the future.

Refactoring is a major part of our
development effort. It was evident to us
that if we were afraid to change some
code because we did not know what it

did, we were not very good developers.
We were letting the code control us. If we
don’t know what the code does now, we
break it and find out. It is better to imple-
ment a solid piece of code than it is to let
a piece of code control the application.

Unit testing was a hard piece to imple-
ment because Forté did not have a ready-
built testing framework. We developed
our own testing framework and have been
successful implementing it. Recently we
started using Java as a development lan-
guage and now use JUnit as a testing tool.

The key to XP is setting developer and
team expectations. We have found all
developers on the team must buy into
Extreme or it doesn’t work. We tell
prospective developers if they do not
want to follow our development style,
this is not a good team for them. One per-
son not buying in to the approach will
bring down the whole team. XP focuses
on the team working together to come up
with new ideas to develop the system.

When we first started with XP, some of
the developers did not want to follow it.
They felt that it would hurt their devel-
opment style and that they would not be
as productive. What happened was that
their pieces of the application were pro-
ducing the most problem reports. Since

they were not developing in pairs, two
people had not designed the subsystem
and their skills were falling behind the
other developers who were learning from
each other. Two well-trained developers
working together and with the rest of the
team will always outperform one “intel-
ligent” developer working alone.

A misconception about XP is that it sti-
fles your creativity and individual growth.
It’s actually quite the contrary. XP stimu-
lates growth and creativity and encourages
team members to take chances. The key is
to decide the direction of the corporation
and stand behind the hard decisions.

XP is not extreme to our team. It’s a
method that uses a common-sense devel-
opment approach. Everyone works to-
gether toward a common goal.

Team: managers, business ana-
lysts, developers, testers, and
technical writers

Application: campaign manage-
ment dbase

Time: three years

October 1999 75

Underestimation
From time to time you will commit to more than

you can accomplish. You must reduce the occurrence
of underestimation as much as possible by getting lots
of practice estimating. If you are overcommited, you
first try to solve the problem in the family. Have you
slipped away from the practices? Are you testing, pair-
ing, refactoring, and integrating as well as you can?
Are you delivering more than the customer needs in
places?

If you can’t find any way to go faster, you have to
ask the customer for relief. Staying committed to more
work than you can confidently complete is a recipe for
frustration, slipping quality, and burnout. Don’t do
that. Re-estimate based on what you’ve learned, then
ask the customer to reschedule. We can only complete
two out of three stories, so which two should we fin-
ish and which one goes in the next iteration or release?
Is there a story that has more critical parts and less

critical parts so we can split it and deliver the most
important parts now and the less important parts later?

Uncooperative customers
What if you get a customer who just won’t play the

game? They won’t specify tests, they won’t decide on
priorities, they won’t write stories. First, by complet-
ing functionality iteration after iteration, and by giving
the customer clear control over development, you are
trying to build a trust relationship with the customer.
If trust begins to break down, figure out if it’s your
fault. Can you do a better job of communicating?

If you can’t solve the problem on your own, you have
to ask the customer for help. Extreme programmers
simply don’t go ahead based on their own guesses.
Explain or demonstrate the consequences to the cus-
tomer. If they don’t change, make your concerns more
visible. If no one cares enough to solve the problem,
perhaps the project isn’t a high enough priority to go on.

DaimlerChrysler: The
Best Team in the World

Chet Hendrickson, DaimlerChrysler

The C3 project began in January 1995
under a fixed-priced contract that called
for a joint team of Chrysler and contract
partner employees. Most of the develop-
ment work had been completed by early
1996. Our contract partners had used a
very GUI-centered development method-
ology, which had ignored automated test-
ing. As a result, we had a payroll system
that had a lot of very cool GUIs, calculated
most employees’ pay incorrectly, and
would need about 100 days to generate
the monthly payroll. Most of us knew the
program we had written would never go
into production.

We sought Kent Beck to help with per-
formance tuning. He found what he had
often found when brought in to do per-
formance tuning: poorly factored code, no
repeatable tests, and a management that
had lost confidence in the project. He went
to Chrysler Information Services manage-
ment and told them what he had found,
and that he knew how to fix it. Throw all
the existing code away! The first full XP
project was born.

We brought Kent in as head coach; he
would spend about a week per month
with us. Ron Jeffries was brought in as

Kent’s full-time eyes and ears. The fixed-
price contract was cancelled, and about
one-half of the Chrysler developers were
reassigned. Martin Fowler, who had been
advising the Chrysler side of the project all
along and clashing with the fixed-price
contractor, came in to help the customers
develop user stories. From there, we fol-
lowed Kent as he made up the rules of XP.
A commitment schedule was developed,
iterations were laid out, rules for testing
were established, and paired programming
was tried and accepted as the standard.

At the end of 33 weeks, we had a sys-
tem that was ready to begin performance
tuning and parallel testing. Ready to begin
tuning because it was well factored and
backed up by a full battery of unit tests.
And, ready to begin parallel testing
because a suite of functional tests had
shown the customers that the required
functionality was present.

That increment of C3 launched in May
1997, not as soon as we had hoped. We
were slowed by two factors. First, we had
decided to replace only the internals of the
payroll system. We left all of the external
interfaces intact. Matching up the output
from our new system to the old payroll
master ended up being a much larger task
then we had originally estimated. Second,
we decided not to launch during any pay
period with special processing require-

ments, such as W-2 processing, profit shar-
ing, or general merit pay increases. This
effectively eliminates November through
April.

Since the launch of the monthly system,
we’ve added several new features, and we
have enhanced the system to pay the
biweekly paid population. We have been
paying a pilot group since August 1998
and will roll out the rest before the Y2K
code freeze in November 1999.

Looking back on this long development
experience, I can say that when we have
fallen short of keeping our promises to
our management and our customers, it
has been because we have strayed from
the principles of XP. When we have dri-
ven our development with tests, when we
have written code in pairs, when we have
done the simplest thing that could possi-
bly work, we have been the best software
development team on the face of the
earth.

Team: 10 programmers, 15 total
Application: large-scale payroll
system

Time: four years

Turnover
What if someone leaves? Won’t you be stuck with-

out documents and reviews? First, a certain amount of
turnover is good for the team and for the people on the
team. However, you’d like people to leave for positive
reasons. If programmers go home at the end of every
week seeing the concrete things they have accom-
plished for the customer, they are less likely to get frus-
trated and leave.

When someone leaves an XP project, it isn’t like
they can take away any secrets that only they know.
Two people were watching every line go into the sys-
tem. And whatever information does walk out the
door, it can’t hurt the team too much because they can
run the tests to ensure that they haven’t broken any-
thing out of ignorance.

New people on an XP team spend the first couple
of iterations just pairing with more experienced peo-
ple, reading tests, and talking with the customer. When
they feel ready, they can accept responsibility for tasks.
Over the course of the next few iterations, their per-
sonal velocity will rise as they demonstrate that they
can deliver their tasks on time. After a few months,
they are indistinguishable from the old salts.

Programmers that don’t work out with the team
are a problem, too. XP is an intensely social activity,
and not everyone can learn it. It also requires aban-

doning old habits, which can be difficult, especially
for high-status programmers. In the end, though, the
many forms of feedback in XP make it clear who is
working out and who isn’t. Someone who consis-
tently doesn’t complete tasks, whose integrations
cause problems for other people, who doesn’t refac-
tor, pair, or test …. Everyone on the team knows the
score. And the team is better off without that person,
no matter how skilled.

Changing requirements
The bugaboo of most software development is just

not a problem in XP. By designing for today, an XP sys-
tem is equally prepared to go any direction tomorrow.
Things that are like what you’ve already done will be
easier, just by the nature of refactoring to satisfy “once
and only once,” but those are precisely the things that
are most likely to happen. However, should a radically
new requirement arise, you won’t have to unwind (or
live with) a lot of mechanism built on speculation.

I didn’t initially realize the extent to which XP can
adapt to changing requirements. The first version of
XP assigned stories to all the iterations in a release,
as part of release planning. The team discovered that
they could get better results with less planning by only
asking the customer to pick which stories should be
in the present iteration. If a new story comes up, you

76 Computer

Ford Motor: A Unique
Combination of Agility and Quality

Don Wells, Ford Motor

Finance Systems at Ford Motor has
been developing the Vehicle Costing and
Profit System (VCAPS), an analysis tool
that produces reports on production rev-
enues, expenses, net income, and profit.
The input is a bill of materials, fixed costs
and expenses, and variable costs such as
labor hours. VCAPS assembles this data
into detailed cost analysis reports to sup-
port corporate-level forecasting and deci-
sion making.

Ford started VCAPS in 1993 and built
it with VisualWorks and GemStone
Smalltalk. VCAPS is now being main-
tained with a small staff and is to be
replaced with a newer system.

The VCAPS project challenged us two
ways. First, the analysts wanted modifica-
tions and new functionality before each
run. Constantly changing requirements
kept us in reaction mode. We never caught

up. Second, the system needed to be run
in a limited span of time. But the system
took a long time to process and required
lengthy manual input before producing
final output. A bug could waste precious
time by requiring a rerun.

XP offered us a unique combination:
agility to meet the volatile requirements on
time and quality to avoid the dreaded rerun.

We began XP with the planning game.
It was a failure. Customers and manage-
ment were unaccustomed to negotiating
schedules. The commitment schedule pro-
duced was perceived as lacking credibility
and utility. We had to swap in Microsoft
Project schedules, which could be modi-
fied without large meetings and could pro-
duce the kinds of artifacts management
was used to seeing and taking action on.

We continued by adding a few unit tests.
Automated unit testing was an enormous
success. After a year, we had 40 percent
test coverage and management had mea-
sured a 40 percent drop in bug reports. XP
was being noticed.

We solved problems by adding XP prac-
tices. Tests enabled continuous integration
and small releases. These allowed us to
roll in collective ownership and refactor-
ing. We were working toward simple
design. Building momentum, we tried pair
programming. We had to work hard to get
pair programming going. Our developers
found it awkward; it took a while to
become comfortable.

After a year and a half, the decrease in
system failures had reduced the number of
emergency releases to a point where cus-
tomers and managers noticed far greater
system stability. Overall, XP was very suc-
cessful in our environment.

Team: 12 programmers, 17 total
Application: cost analysis system
Time: six years

October 1999 77

Tariff System: Tests You Can Read
Rob Mee, Independent consultant

Tariff System is a subsystem of a large
Smalltalk/GemStone project at a major
international container-shipping company.
Using XP practices, Tariff System was
taken from inception to production in
three months by a team of three. The
resulting system proved to be unusually
stable and easy to maintain.

At the outset of the project, the team
resolved to adhere to several core XP prac-
tices: always program in pairs, use the sim-
plest design possible, refactor aggressively,
and write extensive unit tests. All of these
practices were very effective. One XP idea
that initially seemed far-fetched was writ-
ing tests before writing the code that sat-
isfied them. We were surprised to find that
in fact this helped bring our designs into
focus, enabling us to work more quickly.

Another practice we employed from the
beginning was collecting requirements
from users in the form of user stories. We

had mixed results with this. As program-
mers focused on coding, we found the role
of facilitating and negotiating with users
difficult. More important was the fact that
users needed lots of help writing stories
that were both relevant and unambiguous.
In the end, we felt that perhaps XP was
missing a project role. We needed some-
one from the development team whose
primary focus—and particular talent—
was interacting with users.

In our efforts to refactor test cases and fix-
tures, we discovered that creating little lan-
guages for our major domain objects
dramatically improved the readability and
brevity of our test code. It also practically
eliminated the time we spent thinking about
how to create object instances when writing
tests. We defined grammars for about ten of
our domain classes. Here’s a simple exam-
ple used to construct a Service Offering:

newFromString: ‘from Oakland to
Tokyo shipping toys: 20ft containers $500;
40ft containers $1000’.

The constructor uses a parser, automati-
cally generated from a grammar, to pro-
duce the domain object. The code to
instantiate this object using standard con-
structors would have taken many lines,
would have been difficult to read, and
would have distracted from the test case
itself.

Eventually, we discovered that we
could combine the individual domain lan-
guages into a larger description of the sys-
tem as a whole, which proved to be a
valuable tool in the expression of func-
tional tests.

don’t have to shuffle the remainder of the iterations,
you just put it in the pile. One or two weeks later, if
the story still seems urgent, the customer will pick it.

Planning one iteration at a time also introduces a
pleasing self-similarity. At the scale of months and
years, you have the stories in this release and then the
stories in future releases. At the scale of weeks and
months, you have stories in this iteration and then the
stories remaining in this release. At the scale of days
and weeks, you have the task you are working on now
and then the rest of the tasks in the iteration. And at
the scale of minutes and days, you have the test case
you are working on now and then the rest of the test
cases that you can imagine.

X P is by no means a finished, polished idea. The
limits of its application are not clear. To try it
today would require courage, flexibility, and a

willingness to abandon the project should your use
of XP be failing.

My strategy is first to try XP where it is clearly
applicable: outsourced or in-house development of
small- to medium-sized systems where requirements
are vague and likely to change. When we begin to
refine XP, we can begin to try to reduce the cost of
change in more challenging environments.

If you want to try XP, for goodness sake don’t try
to swallow it all at once. Pick the worst problem in
your current process and try solving it the XP way.
When it isn’t your worst problem any more, rinse and
repeat. As you go along, if you find that any of your
old practices aren’t helping, stop doing them.

This adoption process gives you a chance to build
your own development style—which you will have to
do in any case—to mitigate the risks should XP not
work for you and to continue delivering as you
change. ❖

Reference
1. S. Prowell et al., Cleanroom Software Engineering,

Addison Wesley Longman, Reading, Mass., 1999.

Kent Beck owns and operates First Class Software,
your typical one-person consulting company mas-
querading behind a fancy name and an answering
machine. In addition to two books and 50 articles, he
is the author of the forthcoming Extreme Program-
ming Explained: Embrace Change (Addison Wesley
Longman, Reading, Mass., 2000). Contact him at
[email protected].

Team: three developers
Application: shipping tariff cal-

culation system
Time: three months