Change is good

29 May 2007 Change is good

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.