I worked at a company once where the product team was fanatic about Agile. Every standup was attended. Every retro was facilitated. Every sprint was planned with ceremony. The velocity charts looked beautiful. The burndown charts were stable. By all metrics, they were running perfect Agile.
They shipped almost nothing meaningful in two years.
The problem wasn’t that they weren’t Agile enough. The problem was that they were so focused on being Agile that the actual work—shipping products, talking to users, making decisions—had become secondary to the process itself.
The Moment Agile Becomes a Religion
It starts small. You have good Agile practices. You value them. You defend them. But at some point, you slide from “these practices help us think better” to “these practices are the goal.” And that’s when everything breaks.
The symptoms look like this:
You can’t ship anything that isn’t a “Story.” Someone wants to do a quick fix for a one-hour task, but it’s not a story, so it has to wait until next planning. You can’t start anything mid-sprint because sprints are sacred and changing mid-sprint violates the process. You can’t talk to users about their needs directly because that’s “requirements gathering,” which should go through the PM, which should result in a story, which should be estimated, which should be planned. Every action has to fit the ceremony.
Or you have a choice between a two-week solution that requires some off-the-books decisions and a two-month perfect Agile solution where you estimate everything and plan it and get it approved. So you take two months because the process demands it.
Or you’re building a feature, you discover halfway through that you misunderstood the user need, but the feature is already in the sprint backlog, it’s estimated, it’s in the velocity chart, so you ship it anyway rather than pulling it mid-sprint because mid-sprint pivots are against the rules.
Or you do exactly what the process says, and you ship something that nobody wants, but you did it perfectly according to Scrum, so you high-five and move to the next sprint.
The Root Problem
Here’s what actually happened: someone confused the map with the territory. Agile ceremonies are a map. They’re supposed to help you think, coordinate, and deliver. They’re not the territory. The territory is shipping software that solves real problems for real users.
The moment the map becomes more important than the territory—the moment you’re optimizing for process compliance instead of outcomes—you’ve lost the plot. And the scary part is that process compliance is much easier to measure than outcomes.
You can count story points. You can track burndowns. You can measure how many retros happened and how many actions items came out. You can measure velocity. None of this tells you whether you’re building the right thing or shipping anything valuable. But it’s measurable. So it becomes the goal.
And here’s the perverse thing: the more obsessed you become with the process, the harder it becomes to question it. If someone says, “I think we’re spending too much time in ceremonies,” the response is “well, that’s a good retro item,” not actually changing the ceremonies. If someone says, “We shipped a feature nobody wants,” the response is “let’s talk about that in retro and write a better story next time,” not “why did we ship something nobody wants?”
The process becomes insulated from criticism because all criticism is processed through the process. Which means it can never actually be improved; it can only be refined within itself.
The Signs That Agile Has Become a Religion
Velocity is sacred. You’re comparing velocity sprint to sprint, quarter to quarter. If velocity went down, people are concerned about productivity. But velocity doesn’t measure whether you shipped anything valuable. It measures how much story-pointed work you completed. You could have negative velocity—shipping nothing, but on schedule—and as long as you’re being consistent with your estimates, your velocity looks stable.
Ceremonies are non-negotiable. Stand-ups happen even when there’s nothing to stand-up about. Retros happen even when nobody has changed anything and nobody’s going to change anything next sprint. You’re doing them because they’re supposed to happen, not because they’re useful. The calendar owns you, not the other way around.
Jira is the source of truth. Everything has to be tracked in Jira or it didn’t happen. You can’t have a conversation about a problem; you have to write a story first. You can’t decide to skip something; it has to go in the backlog. The system has become more important than the work.
You’re measuring the wrong things. You’re tracking velocity, burndown, story point velocity, estimation accuracy. Nobody’s asking: did we ship something users wanted? Did we talk to users? Did we learn anything? Did we make the right decision? Were we faster than we would have been with a different process?
The process survives contact with reality. You discover you’re building the wrong thing mid-sprint, but you can’t pivot because you committed to the sprint. You’re blocked on something external, but you can’t adjust because the ceremony is sacred. You have a real emergent problem, but it has to go through the normal process, so it waits two weeks until next planning.
What Actually Matters
The Agile values, buried in the Agile Manifesto, are: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan.
Most religious Agile teams have inverted this. They optimize for processes and tools. They document the ceremonies instead of shipping. They negotiate scope instead of collaborating with customers. They follow the plan even when the plan is wrong.
A team that’s actually Agile—not “running Agile ceremonies,” but actually Agile—will break the process when it gets in the way of shipping something valuable. They’ll skip a retro if there’s something urgent. They’ll pull something into a sprint mid-sprint if it matters. They’ll talk to users directly instead of channeling everything through a PM. They’ll make a decision without a story card if the situation demands it.
The process is supposed to help you do these things efficiently. The moment the process prevents you from doing these things efficiently, the process is broken.
How to Dig Out
If you’re in a team where Agile has become religion:
First, ask yourself: what are we actually trying to achieve? Is it “run perfect Scrum,” or is it “ship products that users love”? If the answer is the former, you’re broken. Change it.
Second, measure the right things. Not velocity. Not estimation accuracy. Not how many retro action items you have. Measure: are we shipping? Do users care about what we’re shipping? Are we learning? Are we making better decisions?
Third, question the ceremonies. If a standup isn’t producing synchronization, why are you doing it? If a retro isn’t producing behavioral change, why are you doing it? If planning is just a ritual where people estimate without understanding, why are you doing it? The ceremony isn’t sacred. The outcome is.
Fourth, give people permission to break the process. If someone says, “We should ship this without going through the normal process,” the answer should be “okay, let’s do it,” not “let’s write it up as a story first.” The process is there to help you think. If you’ve already thought and the process gets in the way, skip it.
Fifth, remember that Agile is one set of practices among many. If Scrum is killing your team, try Kanban. If ceremonies are the problem, try event-driven or async. If the whole thing is a religion, change religions. The practices serve you; you don’t serve the practices.
I see this happen a lot in SaaS companies that scale up. You start with a small, scrappy team that ships fast and makes decisions in Slack. Then you hire more people, and suddenly you need process. So you adopt Agile. For a while, it helps—it gives structure to the growth. But then the process becomes the thing, and nobody remembers why they started doing it in the first place.
The teams that stay healthy are the ones that remember: Agile is a toolbox, not a religion. When a tool stops working, you pick up a different tool. When the process gets in the way, you change the process. The goal is always the same: ship good products efficiently.
The moment you start protecting the process instead of protecting the outcome, you’ve lost it.