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

r the accumulated change A after n months can be calculated as A=\frac{1}{(1+r)^n}. Solving for n we get n=\frac{\log{A}-\log{1}}{\log{1+i}}.
Number of months before requirements change has accumulated to 100% of the original requirements.

An increased change rate has a dramatic impact on accumulated change.

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

Just like you can’t build to last on weak foundations, you can’t stay agile without a well-engineered solution.


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]

Image sources

About Greger Wikstrand

Greger Wikstrand, Ph.D. M.Sc. is a TOGAF 9 certified enterprise architect with an interest in e-heatlh, m-health and all things agile as well as processes, methods and tools. Greger Wikstrand works as a consultant at Capgemini where he alternates between enterprise agile coaching, problem solving and designing large scale e-health services

5 Comments

  1. Great post Greger,

    I think the main reason why Agile has become so popular in recent years is most life cycle models were designed assuming requirements were well known up front. Agile methologies assume that requirements will often change.

    Also if a company acheives a competitive advantage using Agile then the competitors usually find this out and start thinking their survival might depend on it.

    • I agree that the idea that requirements can be known upfront has many challenges. Often what is called a requirement is simply a wish or an idea, if it’s not feasible it cannot very well be a requirement, right?

  2. Marcel Körtgen

    Great read! Are you sure the quoted math is 100% correct?

    A = 1 / (1+r)^n

    With (1+r)^n in the denominator, accumulated change would decrease, when change rate r gets bigger.

    I think it should be more like the accumulation function

    a(t)=(1+i)^t

    cf.:
    https://en.wikipedia.org/wiki/Compound_interest#Periodic_compounding
    https://en.wikipedia.org/wiki/Accumulation_function

    • Yes, it seems you are right. I must have made some mistake here or at least I have forgotten how I reasoned.
      10% change rate gives a doubling when 2=1,1^n which gives n=log(2)/log(1,1)=7,3 which I put in the table. Seems the calculation is correct but the formula is wrong. 😉

  3. Pingback: Heraclitus was wrong about innovation - Greger Wikstrand

Leave a Reply