Why Agile Fails — And How to Make It Stick

I have lived through this more than once. You walk into an organization, you can see clearly that Agile would make things better, and you hit a wall. Not a wall of bad intentions — most of the people involved are smart, experienced, and genuinely trying to deliver good work. The wall is something older and harder than that. It is culture. It is history. It is the accumulated weight of a command-and-control framework that has been built up over years, sometimes decades, and that has been working well enough that nobody with real power has had a reason to change it.

And then you show up and tell them they should.

Why Large Organizations Struggle

The Agile Manifesto was written in 2001. But mainstream adoption — real adoption, not just putting "Agile" on a job description — did not come until much later. And even today, after more than twenty years, plenty of large organizations are still working through it.

That is not laziness. It is complexity.

Think about what it actually takes to change how a large bank or insurance company or government agency delivers software. You are not just changing how a development team runs its sprints. You are touching procurement processes, budget cycles, compliance frameworks, vendor contracts, audit requirements, HR performance models, and the deeply held beliefs of dozens of senior leaders who built their careers in a world where a 200-page requirements document was the mark of a professional job well done.

I once worked with a team at a large financial services firm that was genuinely trying to go Agile. They had trained their developers. They had a Scrum Master. They were running sprints. And at the end of every sprint, they were also producing a forty-page status report for the PMO, writing change requests for every story that touched a regulated system, and waiting three weeks for a change advisory board to approve their releases. The team was Agile in the middle and Waterfall at both ends. They were exhausted, and they were starting to blame Agile for problems that were actually caused by everything around it.

That is one of the most common ways Agile fails — not because the method is wrong, but because it gets implemented inside a structure that was never changed to support it.

Command and Control Does Not Go Quietly

Command and control is a deeply human instinct, especially in organizations that have been burned before. When a big project fails — and in traditional delivery models, big projects fail a lot — the organizational response is almost always to add more process, more oversight, more checkpoints. More control. The answer to past failure becomes the cause of future failure, but nobody connects those dots because the mechanism is so slow.

Agile asks leaders to loosen that grip. To trust teams. To accept uncertainty in exchange for speed and adaptability. For someone who has spent twenty years in an environment where certainty — even false certainty — was the currency of credibility, that is a very hard ask.

I have seen Agile transformations derailed by a single senior leader who could not stop asking for a Gantt chart. Not because the Gantt chart was useful, but because it was the thing that had always made them feel in control. Taking it away felt like being asked to fly blind.

How to Eat the Elephant

There is an old question: how do you eat an elephant? One bite at a time.

The same answer applies to Agile adoption. You do not transform a large organization by announcing a transformation. You do it one successful project at a time, building evidence, building trust, and letting the results make your argument for you.

Start with a team that is open to it. Pick a project where the stakes are real but not existential — something with enough visibility to matter, but not so much that a stumble will be used to bury the whole initiative. Run it well. Deliver working software. Show what the retrospective caught that a traditional post-mortem would have missed three months later. Let the people who were skeptical see the difference with their own eyes.

And be willing to make compromises along the way. If the PMO needs a requirements document, write one — but write it from your backlog after the sprint, not before. If the change advisory board needs a release schedule, give them one — built around your sprint cadence. If a senior stakeholder needs a status update in a format they are comfortable with, produce it. You are not betraying Agile by meeting people where they are. You are being Agilish — applying the values and the thinking as far as the environment will currently allow, while continuing to move the needle.

The goal is not to win the argument about methodology. The goal is to deliver great software and let that do the talking.

That is how change actually happens in large organizations. Not with a mandate. With momentum.

Popular posts from this blog

The Agilish Method

Combining Agile and Waterfall methodologies into a cohesive approach, we call "Agilish" can be an effective way to deal with individuals and organizatons that struggle with the natural fuzziness of the Agile approach. Agilish offers the flexibility of Agile while accommodating the structured planning of Waterfall. This hybrid approach can help ensure that projects are adaptable while still meeting deadlines effectively. Here are a few tips to successfully implement Agilish: Start with a Clear Vision : Define the end goal and major milestones upfront, much like in Waterfall. This provides a roadmap that guides the Agile sprints. Iterative Planning : Use Agile sprints for iterative development and planning. Regularly review and adjust plans based on progress and feedback. Strong Communication : Maintain open lines of communication between Agile teams and Waterfall stakeholders to ensure alignment and manage expectations. Flexible Prioritization : Allow for dynamic prioritizatio...
Read more

Agilish — Your Get Out of Jail Free Card

Image
We do not live in a perfect world. Most of our industry has spent the better part of two decades moving toward Agile adoption, and the case for it has never been stronger. But there are still plenty of clients, managers, and organizations that are comfortable with Waterfall — and either will not or cannot change. You can make your case. You can share the evidence. And sometimes, at the end of the day, you are still doing Waterfall. This Dilbert sums up the challenge better than I can: Pick Your Battles Dale Carnegie famously argued that you cannot win an argument . Even when you are right. Even when you have the data. The moment someone feels they are being argued into a corner, they dig in — and you have lost them, regardless of the facts. The same principle applies to how we work and the methods we use. Sometimes the smartest thing you can do is let the client or the manager be right. Not because they are, but because the relationship and the work matter more than winning...
Read more

Blind Alleys and the Case for Incremental Delivery

Image
A friend recently shared a fascinating article about a mistake made by some of the greatest scientific minds of the 19th century. For decades, the best mathematicians and astronomers in the world were convinced there was an undiscovered planet — named Vulcan — orbiting between Mercury and the Sun, hidden from view. The math seemed to demand it. The calculations were elegant. The theory was accepted as fact. There was no planet. A Star-Crossed 'Scientific Fact': The Story of Vulcan, Planet That Never Was Two lines from the article stuck with me. The first: "It's easy to forget that there are people behind the data and equations. And when people are involved, there is always room for human error." The second hit even harder: "In science, you don't dwell on the blind alleys... but the blind alleys are most of what science actually does. You have to go down the blind alley, you bang your head against that blank wall at the end of it, come b...
Read more