Back to news & views

Can Agile address the fallacy of fixed price system developments?

UK HMG recently repaid a contractor £220 million after the failure of the e-Borders project.   £10m of this figure was due to disputed contract changes. Imagine what the total figure might have been including the agreed changes.  Will this be the nadir of the waterfall fixed price contract?  UK HMG is now pushing Agile. It also advocates the use of SMEs as an alternative to big SIs claiming increased value for money and quality.  However can Agile deal with such large-scale developments?

The last 30 years systems development has mostly used the waterfall approach.  All requirements are gathered upfront, a design produced, before finally the development starts.  This approach has two major flaws.

Firstly, for large-scale systems, it takes months if not years before the business see any real output from the process.  In this time, the world has moved on and new requirements emerge.  These are then difficult to accommodate.

The second challenge is due to the nature of IT systems.  Businesses find them hard to articulate and visualise ahead of time.  They often do not know what they want until they see it.

Both the above points are part of a conundrum neatly summarised by

Niels Bohr, “Prediction is very difficult, especially about the future”.  Governments and big businesses rightly require business cases before projects start.  However, these are effectively based on the fallacious assumption their IT departments can make accurate predictions about the future.

So, is Agile an antidote to the failing archaic approach?  Well, as ever, our experience shows it has potential, but it won’t solve all the problems.

Certainly, the two flaws raised above are well covered by Agile.  Requirements are only gathered at a high level at the start of an Agile development.  The development then starts quickly, delivering the agreed priority functionality first.  Secondly, the short sprints allow the business to see what they are getting, allowing adjustment as the delivery progresses.  Changes are easier and cheaper to accommodate when the overall design is not set in stone before development even begins.

However, when large-scale developments are required, there are weaknesses.  As only high-level requirements are available at the start of an Agile project, it is more challenging to estimate costs.  Building believable business cases is harder.  Our experience though is that many waterfall business cases, even though they are based on detailed requirements, end up being substantially wrong.  Apart from optimism bias creating errors, waterfall suffers because, as the e-Borders project shows, the original requirements are wrong and must be changed.  Therefore, this suggests Agile business cases are at least no worse than waterfall versions.

Finally, one area does trouble us when using Agile.  Whilst it is possible to build system functionality in chunks, it is much harder to build the performance and volume requirements in small increments.  No sprint can create the elements that meet the requirement to say support 10,000 simultaneous users.

So, Agile does look like an opportunity to deliver systems more effectively. Our experience of running these projects has seen the benefit of putting the business more in control and by not asking them to be clairvoyants.  The two key differences of early delivery and close business involvement in the development process provide a powerful psychological effect meaning systems produced using Agile are more likely to complete, even in the face of significant challenges along the way.  However, the scale challenge has still to be mastered.