My last post on Agile software development ended on one of the Agile Manifesto key principles – “Welcome changing requirements, even late in development.”

But surely that leads to chaos – how can we possibly build something if we’ve got a moving target ? It must make more sense to gather all the requirements from all the stakeholders, lock them down and then make sure we deliver …

Let’s explore that thought for a moment. It is conventional wisdom that defects are more expensive to fix the later thay are discovered. Requirements are gathered at the start so changing them down stream will be expensive – the further down stream the more expensive.

But what are the costs of not allowing requirements to change ? Even if the solution is delivered on time, on budget and meeting all requirements, research has shown that more than 60% of the functionality is rarely if ever used and only about 20% is used often. Why is this …

  1. The requirements change: Business moves on, and the longer the project the more things change
  2. People’s understanding of the requirements change: People aren’t very good at predicting what they want
  3. People make up requirements: “This is my only chance so I’d better ask for everything I could possibly want”

But what if there was a way to change things ? What if a change to requirements could be made without the expense, or maybe even to save costs or increase benefits ?

The full principle from the manifesto is “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Change happens. Projects are about making change. We can treat changes within our projects as an impediment that needs to be constrained or removed, or we can harness it.


  1. The theory is good, and I hope we can move closer to this ideal. Many of our clients are adopting these sort of approaches and the results speak for themselves.

    One main barrier to these approaches being adopted in the past was the engagement/contract models that our clients dictated. If the project needs a fixed cost, you usually need a fixed set of requirements. This then leads to the “ask for it now or you won’t get it” mentality. No one likes this approach, but in contrast financial controllers *really* hate “I am building a system but I don’t know either what it will cost or what I am getting”.

    Honestly this barrier is only overcome by establishing trusted partnering relationships where both parties are working for mutual benefit. It is something Shine specifically aims for, and I think it is a major reason why our projects are successful.

  2. The irony of course is that in the majority of projects (at least at the start) everyone wants the same thing – the best business outcome and (usually) a way to make life better for the target users. Somewhere along the way something happens … the business gets a better understanding of what they really want, the developers realise that something is much harder than they thought, the world changes in some way.

    So what happens ? The developers know from past experience that they will be punished by the business for delivering late, so they batten down the hatches and try as hard as possible to limit change and reduce scope. The business get frustrated and are ultimately dis-satisfied with the results (even if they are exactly what they originally asked for). But the business learn their lesson – the next time they are involved in a new system they think “ask for it now or you won’t get it” …

Leave a Reply

%d bloggers like this: