Agile practices are 268% more likely to fail than those that aren’t

A recent study has revealed that software projects using Agile practices are 268% more likely to fail than those that don’t.

A recent study has revealed that software projects using Agile practices are 268% more likely to fail than those that don’t.

While this research, commissioned by consultancy Engprax, could be interpreted as a promotion of the Impact Engineering methodology, it raises valid concerns about whether the Agile Manifesto is as effective as commonly believed.

Conducted between May 3 and May 7, the study surveyed 600 software engineers—250 from the UK and 350 from the US. One of the most striking findings was that projects with clearly documented requirements before development were 97% more likely to succeed. This contrasts with the Agile Manifesto’s emphasis on “Working Software over Comprehensive Documentation.”

According to the study, creating specifications before development can improve project success by 50%, and ensuring requirements reflect the actual problem can boost success by 57%.

Dr. Junade Ali, author of Impact Engineering, remarked, “With 65% of Agile projects failing to meet deadlines, it’s time to question Agile’s cult-like following.”

However, other methodologies aren’t without their flaws. Waterfall, for instance, relies on sequential, documented phases, with coding only one part of the process. While Waterfall is easier to manage, it can be slow, costly, and resistant to change, which often prompts teams to explore other approaches.

The study also found that projects in which engineers felt they could freely discuss issues were 87% more likely to succeed. Alarmingly, UK engineers were 13% less likely than their US counterparts to feel comfortable raising problems.

Critics argue that Agile practices are responsible for many of today’s software issues. Frequent patches and incomplete or rushed code have all been attributed to Agile’s focus on speed. One Agile developer even likened daily stand-ups to “a feast of regurgitation.”

Still, the challenges with Agile often arise more from implementation than from the manifesto’s core principles. The misconception that “We don’t need a test team because we’re Agile” is a cost-cutting approach that undermines quality.

This research suggests a balanced approach, emphasizing the importance of a strong requirements-gathering process and creating a safe environment for problem-solving, while also avoiding developer burnout.

The Agile Manifesto has faced criticism over the years. For example, the notorious UK Post Office Horizon IT system, an early large-scale Agile project, suffered from major design flaws, though blaming Agile alone oversimplifies the issue.

Ultimately, the study charts a middle ground between Agile and Waterfall, underscoring that delivering high-quality software on time and within budget requires robust planning and open communication.

0:00
0:00