One of the biggest flaws with the traditional “waterfall” model of software development is that the customer requirements are only validated at the end.
Of course this reveals two types of flaw in the documented requirements:
- They were simply wrong/inadequate in the first place
- They have been overtaken by events
This is particularly obvious in long defence projects like the F35 replacement for the Harrier, or public vanity projects like the Millennium Dome and Scottish Parliament Building.
Much of the cost-overrun of big projects results from the delays and rework costs of enhancing the finished product to meet the newly-clarified/revealed requirements.
So – if you get the requirements right and build to meet them right first time, the project will stand out as being cheaper than normal. The Rion-Antirrion Bridge in Greece is a fabulous example of getting it right first time, and Cross-rail is looking good too.
The huge strength of the Agile approach is that it validates requirements as it goes along, by integrating end users into the development team, and for software development projects this is great (with a couple of caveats). This means that Agile projects have a tendency to be more successful and better value for money.
So is it a no-brainer? Should we do all projects as Agile?
Agile isn’t necessarily cheaper – the Rion-Antirrion Bridge wasn’t Agile, and there are Agile projects that have gone badly wrong.
In my experience, the Achilles heel of Agile is that if the fundamental requirements are not adequately understood at the start, the wrong “architecture” of the solution can be selected and only when a lot of time and effort has been invested does it become clear that you’re on the wrong horse. Swapping horses in mid-stream is difficult and risky, and usually hugely expensive, so the pressure is on to struggle on and make do with what you’ve got.
I prefer a multi-stage approach with rigorous feasibility assessments in managing major strategic projects, where the architecture is really sorted out first. The Rion bridge needed to be tackled as a single entity, because that is the way it functions. Picking the wrong ERP system crippled the business and IT strategy of a FTSE 100 company, leading to a complete U-turn in its IT plans.
Agile approaches have some real benefits, but need using with care, and must not be used as an alternative to thinking the problem through first.