Change is the only constant in agile

[bibshow]

How much change can a project withstand before it is too much? A requirements change rate of above 20% is probably too much [bibcite key=”citeulike:13415962″]. Typical rules of thumb figures for software development requirements change rate is cited as 1-3% [bibcite key=”citeulike:321639″]. But the rate of change is accelerating. In 2002, 10% was not uncommon [bibcite key=”citeulike:13415966″]. How high is it now?

Causes for Requirements Churn

What causes requirements churn? There are basically two schools:

• One school states that requirements change because they were not sufficiently specified from the beginning. If only more care would have been taken upfront, there would not be any problems. Cf [bibcite key=”citeulike:321639″]
• The other school of thought states that requirements change because we have limited knowledge. As the solution, the market and our understanding evolves so do our requirements. Cf [bibcite key=”citeulike:5858976″]

Requirements churn and project failure

There is a rule of thumb that states that only 1/3rd of projects of six months or longer are successful. But it might not be grounded in reality. Research shows that the project success rate is improving and that today as many as 50% of software development projects are successful and only about 30% are total failures. A survey shows that 33% of project failure is attributed to (excessive) requirements change. [bibcite key=”citeulike:4540645″]

Change compounded

Change adds up, just like interest. Requirements may change by 1, 3, 10 or even 20% per month. How long will it be before the compounded change is 100%? Assuming a constant rate of change the accumulated change after months can be calculated as . Solving for we get .

Requirements churn and project success

There are logically two ways to handle change: avoiding change and being ready for change.

Avoiding change

Avoiding change can basically be done in two ways: Having the right requirements from the beginning or keeping the project so short that change won’t have time to accumulate. Having the right requirements must be balanced with the need to respond to change. Naturally, there is a balance to strike but simulations can be used to find that balance. One study recommends spending about 10% of the development budget on systems engineering to avoid rework etc based on misunderstood or poorly formulated requirements. [bibcite key=”citeulike:4540645,citeulike:321639″]. The other solution is to use short iterations (aka sprints). Not that much change can accumulate in two or three weeks.

Being ready for change

Even if we can avoid change for short intervals, sooner or later it will catch up with us. Then we need to be ready for it. And then, what will enable you to deliver change fast? What will enable you to keep a short time to market? In my opinion, what will save you then is a well-engineered system. Just like you can’t hope to build a house on shifting ground you can’t build a system for the long run without good engineering. All the old basics of modularization, clear responsibilities and so on still apply. But it is also important to keep up the quality at all times. Continuous integration and DevOps are excellent ways to do that.

Is there a conflict between doing upfront work and building a solid foundation and being agile? Not necessarily, it is possible and indeed necessary to strike a balance between the two interests if there is going to be anything but short-term agility or long-term rigidity. [bibcite key=”citeulike:6847361,citeulike:13416094,citeulike:13416090″]

References

[/bibshow]