3 Feb 2009

Agile and the cost of change curve

In YAGNI and the cost of change curve we said:

"With traditional "waterfall" approaches it is accepted that it gets more expensive (often much more expensive) if we make changes later in the lifecycle."

"Agile approaches aim to hold that cost of change constant throughout a products lifecycle. If successful, the difference in cost between leaving something until later against doing it now drops toward zero (or less if we discount cash flows)."

So how do agile approaches hold the cost of change constant?

Automate to minimize increases in the cost of change
Often the cost of change is not the change itself, but in dealing with the potential impact of that change. The big risk is inadvertently breaking something. To address that risk we run regression tests.

As the system grows there are more regression tests. Manually testing everything gets very time consuming (days even weeks). Automated tests can be run repeatedly and quickly (seconds and minutes) - keeping the testing costs low.

Another major contributor to the cost of change is the release process. If your system is quick and easy to build, integrate, test and deploy, you can release changes quickly and easily. By automating the release process we can significantly reduce the cost of releases (ideally toward zero).

Write GoodCode to minimize increases in the cost of change
Code is easier to change when it is simple and expressive. The cost of each change is directly related to the number of areas we need to visit to effect that change. Agile approaches value simple, expressive code that has no duplication (DRY code).

But these activities carry both a cost. Neither automation nor code quality comes for free. It takes time and effort to write automation scripts and tests. We need to spend time reviewing and factoring our code to constantly improve the system design.

This means that the costs of change early in a project may be higher in an agile project simply because we are investing time and effort in automation and code quality. The payback comes with every subsequent change.

Bottom Line: If you can't hold the cost of change constant, you are not Agile. While popular Agile processes like Scrum are quiet on these kind of technical practices they still rely on them.