Agile was created to cut through bureaucracy. Somewhere along the way, it became the bureaucracy.
The Ritual Nobody Reads the Manual For
Monday morning. 9am. Your team logs into the standup. Someone goes first: "Yesterday I worked on the payment service. Today I'll continue on the payment service. No blockers." Thirteen minutes later it's over. Everyone goes back to their desks and does exactly what they were doing before.
You've run your Agile ceremony. You haven't done a single thing the people who wrote the Agile Manifesto intended.
What the Manifesto Says
In February 2001, seventeen software developers met at a ski lodge in Utah. They were fed up with heavyweight, document-heavy processes crushing engineering teams. They wrote four values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Read those slowly. Now look at your sprint process.
How much of your ceremony is about processes and tools? How much of your definition-of-done is comprehensive documentation? How often do engineers wait for a refinement session instead of picking up the phone and talking to a customer?
The manifesto's twelve principles include: "Working software is the primary measure of progress." And: "Simplicity... the art of maximizing the amount of work not done... is essential."
Story points. Velocity charts. Capacity planning spreadsheets. Sprint burn-up graphs. None of those are in there.
How We Got Here
I've led engineering teams for years. I've watched the same pattern at every organisation claiming to have "adopted Agile."
Step one: hire a Scrum Master or Agile Coach. Step two: set up Jira. Step three: run two days of training. Step four: start doing two-week sprints with all the ceremonies. Within six months, the team has more meetings than they had before. The ceremonies multiply. A daily standup becomes a standup plus refinement plus sprint planning plus a demo plus a retrospective plus an ad-hoc sync because the planning went sideways.
A methodology created to cut through bureaucracy has become its own bureaucracy.
I spoke to a senior engineer recently who told me their team spends roughly one full working day per week in Scrum ceremonies. Twenty percent of engineering time before anyone writes a single line of code. Their deployment frequency? Once every six weeks. Their lead time from idea to production? Four months.
Not Agile. Scrum theatre.
The Stats Are Uncomfortable
A 2024 study of 600 software engineers in the UK and USA, reported by The Register, found software projects adopting Agile practices are 268% more likely to fail than those without it. The same research found 65% of Agile projects fail to deliver on time, within budget, and to an acceptable quality standard.
These numbers shock people. They shouldn't.
The problem isn't Agile. The problem is what passes for Agile in most organisations. Strip away the mindset, keep only the ceremonies, and you get all the overhead with none of the benefit.
The same research showed projects with clearly defined requirements before development started were 50% more likely to succeed. Requirements... documented in advance. The same thing the Agile world called waterfall thinking.
The lesson isn't "go back to waterfall." The lesson is: know what you're building, talk to the people who need it, and then move fast. Agile thinking, in other words. The sprint ceremony calendar is not.
What Real Agility Looks Like
I've been in teams with genuine agility. They looked nothing like the textbook.
They talked to customers constantly... not in formal quarterly reviews, but in Slack threads and five-minute calls when something was unclear. They shipped small changes often... not because they had a release train scheduled, but because they cared about getting feedback. They changed direction mid-sprint without drama... not because they ignored planning, but because they treated the plan as a starting point, not a contract.
The most effective team I ever worked with had a process describable in one sentence: build something small, show it to someone who'll use it, learn, repeat. No Jira. No velocity tracking. No Scrum Master. A Trello board with three columns. They shipped every week without fail.
Where to Start If Your Agile Has Gone Wrong
Cut the ceremony time in half. Your daily standup should take fifteen minutes maximum... and only when it's genuinely useful. If it's a status report to the manager, cancel it. The manifesto says face-to-face conversation is the most effective way to share information. A round-robin status update isn't a conversation.
Measure outcomes, not process compliance. How often do you deploy? How fast do you respond to a customer request? How long from idea to production? Those numbers matter. Velocity and story points are internal theatre.
Put engineers in direct contact with users. Not via a product manager acting as a translator. Direct contact. This one change does more for agility than any ceremony redesign.
Take "maximising the work not done" seriously. Your backlog isn't a commitment. It's a hypothesis list. Most of what's in there doesn't need building. The most productive decision your team makes in a sprint might be the feature they reject.
The Question Worth Sitting With
Before your next sprint planning, ask your team: are we practising Agile, or are we running Scrum ceremonies while calling it Agile?
The answer might be uncomfortable. Uncomfortable answers are where improvement starts.
Your team's agility isn't measured by how faithfully they follow the Scrum Guide. It's measured by how fast they learn, how quickly they respond to change, and how much working software lands in front of real users.
Everything else is overhead.
What does your team's Agile practice look like in reality? Are you building things... or running meetings about building things?