Picture this. A company spends three months training everyone on Agile. They hire a Scrum Master. They set up sprints, velocity tracking, story points, backlog grooming sessions and a Jira board so complex it requires its own onboarding document.
Two years later, the same company complains their releases take just as long as before. Projects still miss deadlines. Engineers are still burnt out. Stakeholders are still frustrated. Features that should take two weeks routinely take two months.
“Agile doesn’t work,” they conclude.
Agile works fine. The problem is they never actually did Agile. They did a performance of Agile while keeping every structural problem that made their old process slow.
What the Manifesto Actually Says
Before we talk about what went wrong, we need to talk about what was actually promised.
The Agile Manifesto was written in February 2001 at a ski resort in Utah by 17 software developers who were exhausted by the heavyweight, document-heavy processes that dominated enterprise software development at the time. They had all experienced the same thing. Projects where the documentation was perfect and the software was wrong. Processes where requirements were locked down in phase one and changes in phase two cost a fortune. Long development cycles that delivered something nobody wanted.
The manifesto they produced is 68 words long. Four values and twelve principles. That’s it.
The four values are: people and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.
Notice what’s not in there. No mention of sprints. No mention of story points. No mention of velocity charts. No mention of Scrum Masters, product backlogs or two-week delivery cycles. None of the rituals that most teams associate with Agile appear anywhere in the original document.
Those things came from frameworks, primarily Scrum, that were built on top of the Agile values. And somewhere along the way, the frameworks became the point. The values got forgotten.
The Industry That Built Itself on a Misunderstanding
After the manifesto, something predictable happened. Consultancies saw an opportunity. Certifications emerged. Frameworks multiplied. SAFe arrived for large enterprises. LeSS for scaling. DAD for something else entirely. Each one came with its own vocabulary, its own diagram and its own paid training programme.
Agile became a product.
Companies weren’t buying a mindset. They were buying a system. A set of rules they could follow, processes they could implement and boxes they could tick. If you do these specific things in this specific order, you will deliver faster. That was the implicit promise.
It was always a false one because software delivery is not primarily a process problem. It’s a people, communication and culture problem. You cannot solve a culture problem by implementing a ceremony.
But that’s a harder thing to sell than a two-day certification course.
What “Agile” Actually Looks Like in Most Companies
Let me describe a version of Agile that I’ve seen in practice more than once. See if any of it sounds familiar.
Two-week sprints with a planning session that takes three hours because the tickets were written the morning of the meeting and nobody has thought about them properly. Daily standups where developers read their Jira ticket IDs out loud to a manager who nods along. Sprint reviews where the demo is always “almost ready” or presented from a staging environment that doesn’t reflect production. Retrospectives where the team fills in a Miro board with sticky notes, agrees on three action items and never looks at them again.
At the end of each sprint, thirty percent of the committed tickets roll over to the next one. The product backlog has 400 items in it, 200 of which were written two years ago and are no longer relevant to anything. Velocity is a number that fluctuates by 40% every sprint depending on how many people were on leave. The Scrum Master spends most of their time chasing status updates and updating a dashboard that nobody reads.
And somehow, despite all this structure, all these meetings and all this tracking, the software is still delayed. The stakeholders are still surprised when things aren’t ready. The engineers are still working late before launches.
Now change the vocabulary. Replace “sprint” with “phase.” Replace “standup” with “status meeting.” Replace “backlog” with “requirements document.” Replace “velocity” with “project tracker.”
What you have left is Waterfall with worse documentation and more meetings.
The Real Reasons Delivery Is Still Slow
Let’s stop blaming the framework and start being honest about the actual problems.
Requirements arrive broken and keep changing. This is the oldest problem in software and no methodology solves it. If the people requesting features haven’t thought clearly about what they actually need, the team will spend weeks building something that gets revised immediately after it ships. Agile was designed to reduce the cost of changing direction, not to make it free. If your stakeholders treat every sprint as an opportunity to rethink the last sprint’s work, your team will never build momentum.
Decisions require too many approvals. Agile assumes that teams have genuine authority to make decisions about how they build things. In most organisations, that authority doesn’t exist. Architecture decisions get escalated. Technology choices require sign-off. Even small scope changes need a meeting. Every approval in the chain adds delay that no sprint velocity measurement captures.
Teams carry too much technical debt to move fast. Pressure to deliver keeps teams from taking care of the codebase. Tests don’t get written. Refactoring doesn’t happen. Documentation stays outdated. The debt accumulates invisibly until a “simple” feature takes three weeks because six other things have to change to accommodate it. This is an engineering discipline problem that no framework solves.
The team is not actually cross-functional. Agile works when everyone needed to deliver a feature sits on the same team. When design is a separate team, QA is a separate team, security review is a separate team and deployment requires a different team, every feature involves multiple handoffs. Each handoff is a queue. Each queue adds delay. You can run the most disciplined sprints in the world and still miss every deadline because you’re waiting for a team that has its own backlog and its own priorities.
Estimates are treated as commitments. This one is subtle but damaging. When a developer says a feature will take three days, that’s an estimate based on current knowledge. When a manager hears that and books the launch date three days later, the estimate has become a commitment. If anything goes wrong, the commitment is broken. Engineers who learn that their estimates become commitments start padding them. Velocity becomes a fiction everyone agrees to maintain.
The Agile Transformation That Changed Everything Except the Work
I’ve seen companies go through formal Agile transformations. New tools, new vocabulary, new ceremonies, external coaches, weeks of training. And then nothing real changed.
The same people still made decisions at the top and handed them down. The same pressure to hit arbitrary dates persisted. Engineers were still pulled into unplanned work mid-sprint because “it’s urgent.” The product owner had the title but not the authority to actually own the product.
The transformation changed the language everyone used. It didn’t change the power structure, the communication patterns or the culture. And those three things are what actually determine how fast software gets delivered.
Agile is fundamentally about shortening feedback loops. Getting real information faster, responding to it honestly and making small adjustments continuously. None of that requires a specific framework. All of it requires an organisation that values real feedback over comfortable narratives and honest assessment over optimistic reporting.
If your company culture punishes people for raising problems, no amount of retrospectives will surface the real issues. If your management team rewards confident predictions over honest uncertainty, your estimates will always be wrong in the same direction. If your stakeholders don’t trust the development team, no sprint review will satisfy them.
These are not Agile problems. They are human and organisational problems that Agile, done properly, creates space to address. But you have to actually address them.
What Actually Makes Teams Deliver Faster
I’ve been part of teams that delivered consistently and teams that never did. The difference was never the framework.
The fast teams had small backlogs with well-understood items. They had short feedback loops with real users or stakeholders who could tell them quickly whether something was on track. They had genuine trust between product and engineering. They had space to fix problems when they found them rather than shipping around them. They had clear ownership of decisions so things didn’t get stuck waiting for approval.
None of that requires Scrum. Some of those teams used Kanban. Some used a lightweight planning approach with no formal name. Some ran daily standups and some didn’t. The process adapted to the team, not the other way around.
That’s what the Agile Manifesto was actually asking for. Not a specific set of ceremonies but a specific set of priorities. Working software. Real collaboration. Honest response to what you learn.
Most companies implemented the ceremonies and never addressed the priorities. Then they wondered why the ceremonies didn’t help.
The Honest Conversation Most Teams Avoid
If your delivery is still slow after two years of Agile, the answer is not a new framework or a stricter version of the current one. The answer starts with an honest conversation about what is actually getting in the way.
That conversation is uncomfortable because the real blockers are usually things people in positions of authority are creating. Unclear priorities coming from the top. Scope that keeps growing because nobody is willing to say no to stakeholders. Technical problems that keep getting deferred because there’s no time to address them.
Agile can’t fix any of that. Only honest leadership and genuine change in how decisions get made can fix it.
The good news is that once you stop expecting the framework to do the cultural work, you can start doing the cultural work directly. And that’s where delivery actually improves.
The Agile Manifesto closes with a note that the authors value the items on the right but value the items on the left more. Working software more than documentation. People more than process. Most Agile implementations got that exactly backwards.