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.