Tue, 09 Nov 2004
Adding a basement to the house
Agile methods people claim changed requirements late in
a project are not a disaster. Skeptics claim that's impossible,
that it's like finishing the first story of a house and then
deciding you want a basement.
That's a misguided analogy. The reason putting in a basement after the
walls are up is hard is because almost no one does it. If it was
done to every house during construction, you may be sure that
homebuilders would have learned to do it as cheaply as is physically
Agile projects don't think ahead: in iteration N, they don't pay
much attention to what's coming in iteration N+1, much less
iteration N+5. That means that every iteration brings with
it a whole slew of what are, in effect, changed requirements. That trains both the
software and the team to handle change as cheaply as is
It's like the way that just-in-time inventory management
forces factories to improve their production process. Because they
cannot buffer asynchronies with stock on hand, they are forced to
remove them. (See The Machine That Changed the World.)
## Posted at 23:53 in category /agile
The cost of change curve
Everyone knows the canonical cost of change curve (first image), where the cost
of a change rises exponentially throughout the project.
Let's pretend it's a law of nature, as many many project planners
before us have done.
Now suppose someone notices they need to change a
requirement in the middle of the project. The cost of change curve
says that the change would be far too expensive. So it's not made.
Fine. But we know that almost every product that's actually
used gets re-released with new features added. Most usually, the
next project starts as soon as the previous one finishes. According to the
cost of change curve, that's exactly at the point where the costs
are highest (second image).
The decision to postpone changes can only make sense if the cost of change
resets to something much closer to the far left of the
curve (third image). What's supposed to make that happen? And why doesn't that
operate in the middle of the first project's curve?
These are serious questions, even though I suspect
being stupid. I'm writing a book chapter that explains conventional and agile
software development to an audience of sociologists, and this
occurred to me.
Mail me, and I'll summarize.
## Posted at 09:18 in category /misc