Agile approaches and achieving project quality

‘Agile’, as a collective term for a general iterative approach to projects, and set of methods including Scrum, SAFe and DSDM, is a hot topic for many reasons, some good, others not so good.

The primary good reason is that an agile approach is more likely than a classic waterfall approach to deliver a solution that is fit for purpose, meeting business needs and delivering the benefits expected i.e. a ‘quality solution’.

Why?

The following key factors of an agile approach combine to deliver quality:

1. There is an integrated team involving end users and other key stakeholders throughout, steering the solution towards meeting their business needs. Requirements are validated as the project progresses, not during final acceptance testing.
2. Requirement prioritisation and risk management are a team activity, looking at all stakeholders’ perspectives holistically and ensuring that no one’s requirements are ignored or overlooked.
3. Incremental development allows progressive understanding of what a good solution will do, and how it will work, building tomorrow’s solution today, not yesterday’s solution tomorrow. It’s very hard, especially with complicated projects, to get innovative requirements right up front.
4. Acceptance testing is embedded at every step – there can be no build-up of untested features that demand rework later

Fantastic. Agile must be the answer to all our project success issues, surely?

Well, no.

Agile or iterative approaches are susceptible to a critical issue, ‘false start’ or 'you want to get to where? I wouldn’t start from here if I were you'.

If there isn’t enough thought going into the project up front, it’s easy to head off in the wrong direction, literally with the wrong foundations. This can be the wrong technology, the wrong infrastructure, the wrong team or simply the wrong holes in the ground. This leads to a major dilemma later, when substantial investment has been made – do we scrap all this and start again, knowing what we now know, or do we kludge this into something workable for now, but which will need replacing soon?

If enough cost has been sunk in the project, few decision-makers have either the power or the courage to scrap and start again, so unless it’s indisputable that finishing the project is impossible using the current approach, the project goes on to be a white elephant – way late, way over budget and delivering a fraction of the benefits forecast. This isn’t just true of IT projects, the birthplace of agile methodologies, but civils projects too. The story of the UK’s Advanced Gas Reactor power stations is one where some started to build too soon (the ‘rush to concrete’) and later facing massive delays and cost over-runs from redesign and rework. In contrast, the Rion-Antirion bridge mentioned in an earlier blog post delivered early and on budget due to the rigorous preparation before starting any construction work.

Does this mean avoid agile methods? Not at all, just that they need to be used carefully in a context-sensitive way.

For IT projects, where the detailed functional requirements are unclear but the infrastructure is pretty certain – use agile methods out the box. This is what they were developed for and they are excellent.

For everything else, consider using a multi-step hybrid approach:

1. During the concept phase, use agile approaches to create and modify concept demonstrators, digital models etc to explore and validate the requirements. They are fantastic for probing and understanding the requirements, moving stakeholders’ thinking into the future.
2. During project definition, use agile methods to explore alternative solutions, perhaps using digital twins, computational fluid dynamics, BIM models etc then developing and thoroughly testing how well the proposed solution will meet the requirements before committing to the final design and project baseline
3. Build the solution, fully engineered, using a waterfall approach. The lack of rework and redesign will result in its delivery as quickly and cheaply as possible.

Outcome? Success.

I’ve successfully used this approach on a range of complex projects over the last 30 years with organisations including Rolls-Royce, Fujitsu, Vodafone and the Royal Navy, and it works. It’s not easy to get management buy-in to this investment up-front in getting it right, but it pays back later when the final solution is on time, on budget and exceeds expectations. Sadly, I’ve also seen some awful failures where this recommendation has been rejected – largely due to time pressures. More haste, less speed.

The next blog post will look at making quality management easier for projects, making success more likely.

You may also be interested in:

• What is quality management?
• Project Success and Quality: Balancing the Iron Triangle
• Successful quality management requires expert risk management