This is a quick’n’dirty picture of the cost of change (y) against time (x) on a Big Design Up Front project (red) and an Agile one (green). For the colour-blind, the Agile cost is the one that stabilises with time, rather than growing exponentially.
This is how the argument goes:
- In a BDUF project, the requirements are elicited from the customer and written down. If at any point the requirements change, the document must be updated.
- Then the requirements are turned into a high level design. If the requirements change, the high level design and the requirements document have to be updated.
- Then the high-level design is turned into a more detailed low-level design. If the requirements change, the high level design and the requirements document and the low-level design document have to be updated.
- Then the code is done. After that, the code is tested. Then, the code is integrated. Now if the requirements change… well, you get the picture.
- In an ideal Agile project, because the code is largely self-documenting, we don’t do any more design up front than we have to and we practice continuous test, *integration, release and many other forms of frequent feedback, the cost of change is kept low.
I would like to remind myself and anyone else who needs it that the cost of change on an Agile project, while comparatively small, is not zero.
Update: The quick’n’dirty explanation and picture above are huge approximations meant to serve as a rough context for the reminder at the bottom – the non-zero cost of change. There are better explanations and more accurate pictures around which have been crafted by far greater authors. Apologies to anyone who thought I was redefining the wheel; I have added the * clauses for clarification.
Liz Keogh, lunivore 
And also, because we assume from the beginning that things will change, we do things to support this, like fully disciplined BDD, using mocking (and hence dependency injection) to help us, with a bit of refactoring when we’re done. This tends to leave us with a nicely decoupled, well turned-over architecture (and incidentally a whole heap of behaviour definitions (tests) as a safety net). Exactly the sort of architecture that’s amenable to changing individual pieces without the changes rippling through a thousand dependent parts of the system.
Michael Feathers defines legacy code- the kind of brittle, nasty code that ends up being cheaper to rewrite than refactor- as code without good test coverage. I’ve always really liked that.
While the curve is right, your explanation is not. Having lightweight artifacts and CI tools helps, but it is not the main factor for flattening the cost of change.
In an Agile project if requirements change you still have to go back and rewrite the requirements (even if is is only “on the wiki”), and change your design (even if it just a picture you took from the whiteboard with your mobile/cell phone camara), and change your tests (even -or especially- if they are automated).
What makes the difference in an Agile project is that because you work highly iteratively and adaptively you get feedback a lot quicker from your customers and testers. If you got something wrong it’s only a small increment that you have to “undo” or fix. Contrast that with waterfall where customers and testers don’t get to see the software until months, sometimes years after they specified it. If despite all your Big Upfront Analysis and Big Upfront Design you got something wrong there is so much software already written on top of the wrong requirements/design that the cost of chaning it snowballs.
Working in small increments, rapid feedback, frequent reflect/adapt cycles is the differentiator. Not the absence of heavyweight documents or CruiseControl.
–agilechilli (ex TWer)
I can’t believe you’re repeating these nonsensical statistics. The “flat cost of change” is rubbish. It was originally described as a “what-if” scenario in the first XP book (have you actually read it?), but has since been repeated parrot-fashion by ThoughtWorks in their marketing literature and by other people who don’t actually think about software project management.
See update above, sorry.
Corrected. Thank you!
Do you realise that the y-axes of the two curves are measuring different things and so cannot be compared?
I haven’t labelled the x-axis, either, but they’re both defined in the paragraph below.
The y axis is the cost of change. Would you like me to add the words “in money” (comparable in many denominations last time I heard)? I appreciate that it might be a bit subtle as it stands.
I could even make it bold and flashing for you, if you like.
You really don’t understand it, do you?
The y-axes of the two curves are showing costs of DIFFERENT THINGS and so cannot be compared. Just because you repeat the nonsense that they are both showing cost of change doesn’t make it true.
Look at the picture, and tell me what you see.
I see sloppy thinking (at best) or deliberate misinformation (at worst).
Why don’t you define what you mean by “change” for each of the curves?
Why don’t you at least try to draw the two curves to scale?
Why do you not take into account the cost of learning what change is required in the “bduf” curve, when you assume it in the “agile” curve? (Hint, that completely changes the shape of the “bduf” curve).
Why don’t you show that the cost of discovering the need for and making a change during the maintenance phase does not go exponential for “bduf” but is about the same for both types of project?
Why don’t you show that the cost of making the change is typically *lower* for “bduf” projects because they have better maintenance documentation for the support team?
Alistair Cockburn wrote about this in quite a bit of detail back in 2000:
http://www.xprogramming.com/xpmag/cost_of_change.htm
Why don’t you define what you mean by “change” for each of the curves?
Because most of the readers who might be interested in this post are capable of imagining a typical change that might be made to a system in development. One I keep encountering involves the independent system we’re talking to finally being completed, and not actually meeting the specs we were given. You can use that if it helps.
Why don’t you at least try to draw the two curves to scale?
Because I’m an atrocious artist, so I qualified my graph with “quick’n’dirty” to indicate that it shouldn’t be taken as seriously as you’re taking it.
Why do you not take into account the cost of learning…
Because I didn’t need to to make my point about the non-zero cost of change on agile project.
Why don’t you show that the cost of discovering the need for and making a change during the maintenance phase does not go exponential for “bduf” but is about the same for both types of project?
Because I hadn’t thought about the maintenance phase… but having been on support in both Agile and BDUF projects, I believe it’s lower for Agile projects – especially if you treat your support staff as end-users of the application and get their changing requirements from them too.
Why don’t you show that the cost of making the change is typically *lower* for “bduf” projects because they have better maintenance documentation for the support team?
That’s another problem; the documentation on most BDUF projects I’ve been on was out of date by the end of the project, and therefore not useful for support. Self-commenting code and descriptive tests are still my favoured form of documentation.
Thanks, I shall include this link the next time I attempt to make any related comment. 🙂
Why do you need to remind yourself that the cost of change of an Agile project is non-zero? Whoever needs to make the change must be paid and use equipment and facilities that have running costs. Of course the cost of change is non zero. Even with a liberal sprinkling of magic Agile pixie dust, change is never going to magically cost nothing. In fact, I cannot believe you ever thought it did. So why did you post this?
I’ve never thought the cost of change was zero, just forgotten about it occasionally. I find it very easy to say “Sure, no problem!” when the customer requests a small change in the demo, without remembering that a) the costs of small changes add up, and b) each change is a new story (or at the very least, scope creep). My helpful, can-do attitude is colliding with reality (and deadlines), and I’m not the only one.