Yes but no!

An apparent study from Engprax has shown in 2024, software projects adopting Agile practices & ways of working are 286% more likely to fail than those that do not!

Now hold on a f***ing minute, if I make a living about extolling the virtues of Agile, this is not what I want to hear right? Dr Junade Ali, author of Impact Engineering (quoted from the website above), said: “With 65 percent of projects adopting Agile practices failing to be delivered on time, it’s time to question Agile’s cult following. And I completely agree with this.

You see, for quite some time I’ve found a huge chasm between those who ‘understand’ the sentiment of the manifesto, & those who sit in middle-management glomming onto massive process diagrams of Scrum & other associated Agile components & hoping they know what’s going on in their respective change programmes,  – you know, that false sense of security just like Waterfall! It gives Agile & the associated manifesto a bad name & has plagued my projects as I spend time unpacking & fixing a previous. Bodged attempt at change. (we all think we’re the saviours though right?) When the Agile Manifesto was introduced in 2001, it was heralded as a groundbreaking shift in how software development projects should be managed and delivered. The manifesto’s principles promised a better way—one that valued individuals over processes, working software over comprehensive documentation, collaboration over contract negotiation, and responsiveness to change over rigid planning. At its core, the manifesto sought to address the frustrations developers and project managers faced in the rigid, waterfall-style frameworks of the time.

Two decades later, the Agile Manifesto has undeniably shaped the industry. Scrum, Kanban, and SAFe dominate project management conversations. “Being Agile” has become a cultural aspiration within organisations worldwide. And yet, for all its influence, the Agile Manifesto has arguably failed to deliver on its utopian promises. Instead, it has inadvertently contributed to the very issues it set out to solve, with many projects derailing due to the overzealous and dogmatic adoption of Agile practices.

In this post, I want to explore why the Agile Manifesto isn’t all it’s cracked up to be and how its principles have sometimes exacerbated, rather than resolved, software development challenges.

I’m going to have one more go to try & get people to understand – John Kern

Reference here to see what John Kern is saying about Agile.

The oversimplification of the manifesto

At first glance, the principles of the Agile Manifesto appear simple and intuitive. But therein lies the first problem: simplicity can be deceptive. For instance, prioritising “individuals and interactions over processes and tools” is a noble idea, but it has often led to chaos in execution. In real-world projects, especially those involving hundreds of team members spread across multiple geographies, processes and tools are not just helpful—they are essential for alignment and efficiency.

Many organisations took the Manifesto’s disdain for processes and documentation as a green light to abandon structure entirely. The result? Projects without clear requirements, vague success criteria, and teams constantly chasing moving targets. Without a balance between flexibility and discipline, the “interactions over processes” mantra becomes a recipe for disorganisation.

Agiles open door to scope creep

One of the most lauded aspects of Agile is its embrace of change. The idea that teams should “respond to change over following a plan” has been weaponised by stakeholders and executives as an excuse to avoid making firm decisions. In practice, this often leads to scope creep, where additional features or requirements are added mid-sprint or even late in development.

While Agile frameworks like Scrum offer mechanisms like backlog grooming to manage this, the cultural emphasis on accommodating change can undermine a team’s ability to deliver incrementally. Teams are often left juggling too many priorities, with sprints becoming chaotic firefights instead of disciplined efforts to deliver value.

Moreover, constant changes make it nearly impossible to measure progress effectively. If the goalposts keep moving, how can success be defined or achieved? This dynamic has contributed to an untold number of projects failing to deliver on time, within budget, or even at all.

The Dogma of Agile purity

Another unintended consequence of the Agile Manifesto is the rise of what I call “Agile fundamentalism.” This phenomenon occurs when organisations and teams adhere rigidly to Agile practices at the expense of pragmatism. For example, some Scrum Masters insist on conducting all prescribed ceremonies—daily standups, sprint retrospectives, planning sessions—even when they add little value to the project at hand.

Agile was meant to be a flexible framework that could adapt to the needs of a project. However, it has often been implemented dogmatically, with practitioners treating the manifesto as scripture. Teams get caught up in “being Agile” rather than focusing on delivering quality software. Ironically, this rigidity is the antithesis of what Agile was designed to promote.

Agile’s mis-alignment with business priorities

One of the core issues with the Agile Manifesto is its failure to fully acknowledge the realities of business. Stakeholders often need fixed timelines, budgets, and deliverables. While Agile preaches iterative delivery and constant evolution, businesses frequently require predictability—something Agile struggles to provide.

This disconnect creates friction. Agile teams want to focus on delivering increments, while executives demand roadmaps and firm commitments. Agile practitioners often view these requests as relics of outdated thinking, but the reality is that business leaders have valid concerns. After all, organisations have customers, shareholders, and market pressures that demand clarity and predictability.

The manifesto’s dismissal of “contract negotiation” in favour of “collaboration” further highlights this misalignment. In practice, software projects often involve multiple vendors, external partners, and legal agreements. Contracts exist for a reason: to ensure accountability and clarity. While collaboration is essential, it cannot replace the need for clear terms and conditions.

The industrialisation of Agile

Perhaps the most significant way the Agile Manifesto has gone astray is through its commercialisation. Agile, once a grassroots movement, has become an industry in its own right. Certifications, training courses, and consulting services have turned Agile into a billion-dollar business. Frameworks like SAFe and LeSS have layered complexity onto the original principles, creating entire ecosystems that feel anything but “lightweight.”

This industrialisation has diluted Agile’s original intent. Instead of fostering creativity and collaboration, it has become a checkbox exercise. Teams go through the motions of sprints and ceremonies without truly embracing the manifesto’s values. Worse, organisations often invest heavily in Agile transformation initiatives only to see minimal returns, as they’ve implemented process changes without addressing cultural or organisational barriers.

How Agile contributed to failed projects

The gap between the ideals of the Agile Manifesto and its real-world implementation has directly contributed to software project failures. Here are some common scenarios:

1. Poorly Defined Requirements: By de-emphasising upfront planning, Agile has sometimes led teams to start projects with insufficient understanding of what success looks like. This lack of clarity creates rework and delays.
2. Burnout Culture: The emphasis on rapid delivery and constant iteration can lead to team burnout. Without adequate time for reflection and rest, developers become fatigued and less productive.
3. Over-Promise, Under-Deliver: Agile’s focus on delivering increments can lead to a myopic view of progress. While stakeholders see frequent releases, the lack of a cohesive end goal can result in a product that feels incomplete or incoherent.
4. Conflict Between Teams and Stakeholders: Agile’s principles often clash with traditional business expectations. This tension can create a toxic environment where teams feel undervalued and stakeholders feel ignored.
5. Lack of Accountability: Without detailed documentation or contracts, it becomes difficult to hold teams or vendors accountable when things go wrong. Agile’s preference for flexibility can sometimes translate into a lack of ownership.

What needs to change?

It’s not all doom and gloom. The Agile Manifesto still has valuable lessons to offer, but it needs to be revisited and contextualised for today’s realities. Here are a few suggestions:

1. Embrace Hybrid Models: Combine the best of Agile with traditional methods to create a balanced approach. For instance, upfront planning can coexist with iterative delivery.
2. Redefine Success Metrics: Move beyond velocity and burndown charts to include measures of value delivered, team satisfaction, and customer impact.
3. Tailor Agile Practices: Treat Agile as a toolbox, not a rulebook. Use only the practices that add value to your specific context.
4. Invest in Culture: Agile transformations should focus on fostering a culture of trust, accountability, and collaboration rather than blindly implementing frameworks.
5. Acknowledge Business Realities: Work with stakeholders to find a middle ground between Agile flexibility and the predictability businesses require.

Conclusion

The Agile Manifesto was a bold attempt to reshape software development for the better. And while it has undeniably had a positive impact, its principles have also been misinterpreted, misapplied, and over-commercialised. Agile’s promises of faster delivery, improved quality, and happier teams have often fallen short, leading to failed projects and frustrated stakeholders.

To move forward, we need to stop treating the Agile Manifesto as gospel and start viewing it as a set of guiding principles that must be adapted to fit the complexities of modern software development. Only then can we truly realise its potential and avoid repeating the mistakes of the past.