Study finds 268% higher failure rates for Agile software projects
In praise of knowing the requirements before you start cranking out code
A study has found that software projects adopting Agile practices are 268 percent more likely to fail than those that do not.
Even though the research commissioned by consultancy Engprax could be seen as nothing more than a thinly veiled plug for the Impact Engineering methodology, it feeds into the suspicion that the Agile Manifesto might not be all it's cracked up to be.
The study's fieldwork was conducted between May 3 and May 7 with 600 software engineers (250 in the UK and 350 in the US) participating. One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is "Working Software over Comprehensive Documentation."
According to the study, putting a specification in place before development begins can result in a 50 percent increase in success, and making sure the requirements are accurate to the real-world problem can lead to a 57 percent increase.
Dr Junade Ali, author of Impact Engineering, said: "With 65 percent of projects adopting Agile practices failing to be delivered on time, it's time to question Agile's cult following.
"Our research has shown that what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout."
The Agile Manifesto has been criticized over the years. The infamous UK Post Office Horizon IT system was an early large-scale project to use the methodology, although blaming an Agile approach for the system's design flaws seems a bit of a stretch.
- Report: 83% of UK software engineers suffer burnout, COVID-19 made it worse
- 'Business folk often don't understand what developers do...' Twilio boss on the chasm that holds companies back
- IBM warns Global Tech Services staff that 346 UK heads will roll in latest redundancy action
- Erik Meijer: AGILE must be destroyed, once and for all
It is also easy to forget that other methodologies have their own flaws. Waterfall, for example, uses a succession of documented phases, of which coding is only a part. While simple to understand and manage, Waterfall can also be slow and costly, with changes challenging to implement.
Hence, there is a tendency for teams to look for alternatives.
Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed, we're told. Worryingly, workers in the UK were 13 percent less likely to feel they could discuss problems than those in the US, according to the study.
Many sins of today's tech world tend to be attributed to the Agile Manifesto. A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.
One Agile developer criticized the daily stand-up element, describing it to The Register as "a feast of regurgitation."
However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. "We don't need a test team because we're Agile" is a cost-saving abdication of responsibility.
In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates. ®
Addendum
For those unhappy with the not-entirely-scientific study quoted above, check out our interview here with Agile Manifesto co-author Jon Kern about it all.