Scrum is not a religion.
Here is when to drop it.

I have facilitated hundreds of Scrum ceremonies. Daily standups at 9.02am where nobody was really talking to anybody. Four-hour sprint plannings that produced a sprint backlog nobody believed in. Retrospectives where the same problems came back week after week, covered over with a fresh layer of sticky notes.

At some point I stopped asking myself "how do we do Scrum better?" and started asking "is Scrum the right tool here?"

That is not the same question.

Scrum is a tool, not an identity

The Scrum Guide is 13 pages long. It describes an empirical framework for tackling complex problems in uncertain environments. Nowhere does it say that you have to apply it to the letter in every context, for every team, at every stage of growth.

And yet, in a lot of organisations, Scrum has become an identity. "We are agile." "We do Scrum." That semantic shift is dangerous: the moment the framework becomes an identity, questioning it becomes a personal threat to the people who adopted it.

That is where it seizes up. Not in the framework itself — in the emotional attachment to the method.

A good Scrum Master is the one who knows when to stop doing Scrum.

Signal 1: the ceremonies are still there, but nobody believes in them

You know this meeting. The daily standup at a fixed time, 15 minutes on the clock, everyone reciting their "yesterday / today / blockers" triptych — then heading back to their desk without a single thing having changed.

People are there physically. Mentally, they are answering their emails.

This is not a facilitation problem. It is a weak-signal problem: the ceremony exists because it has always existed, not because it produces value. When nobody would even miss the standup if it vanished tomorrow, the standup has stopped serving a purpose.

The signal to watch for: the real lifespan of decisions taken in a ceremony versus outside one. If the actual decisions get made in corridors, in Slack DMs, or in ad hoc meetings — and the ceremonies only exist to rubber-stamp them — the ritual has lost its usefulness.

Signal 2: sprint planning takes 4h and produces 0 clarity

A good sprint planning produces three things: a clear sprint goal, a sprint backlog the team has accepted, and collective confidence that the sprint is actually feasible.

When the meeting runs four hours and nobody really knows what we are doing this sprint or why — something fundamental is broken. Either the user stories turn up too vague, or the backlog has not been refined, or the sprint goal does not exist in practice.

But the real problem often runs deeper: the team is not dealing with "complex" problems in the Cynefin sense — it is dealing with well-defined projects, with clear specifications, in a domain it already knows. In that case, a 2-week sprint with the full set of ceremonies is dead weight, not an advantage.

Signal 3: the team talks in "points" but cannot say what it is shipping

Story points are an abstraction for estimating relative complexity. They have no value in themselves. When a team optimises its velocity in points but struggles to answer "what did you ship to your users this month?", the measure has taken the place of the goal.

That disconnect — between the framework's internal metrics and the value actually produced outside it — is one of the surest signs that Scrum has stopped being a tool and become an end in itself.

When Scrum genuinely holds up

To be fair: Scrum is excellent in the right contexts. It shines when:

• The problem is genuinely complex and the solutions are not known in advance
• The team is stable, small (3-9 people), and multidisciplinary
• The stakeholders are available for frequent feedback
• The product is alive and evolves in response to continuous learning

If you tick those four boxes, Scrum is probably your best tool. Keep it.

Three alternatives worth knowing

Shape Up (Basecamp)

6-week cycles with an appetite fixed up front — not estimates, but a political decision about what you are willing to invest. The team has complete autonomy over implementation within the bounds of the cycle. No permanent backlog. No sprint debt. Excellent for mature product teams with well-scoped projects.

Flow-based Kanban

No sprints, no velocity. A continuous flow with strict WIP (Work In Progress) limits. Each ticket comes in when it is ready and leaves when it is done. Average cycle time replaces velocity as the performance metric. Ideal for teams handling a lot of incoming requests of varying size — support, ops, platform.

Project mode for small teams

Sometimes the right answer is plain old project management. One objective, one scope, one deadline, one plan. No ceremonies, no Scrum roles, no sprints. For an MVP with 2 devs and 12 weeks, that is usually more than enough — and infinitely cheaper in overhead.

How to make the transition without breaking everything

Moving from one framework to another is less a technical problem than a human one. A few rules:

• Never kill Scrum "from above". If the decision comes from management alone, the team will resist. The transition has to be built together, with a dedicated retrospective to name clearly what has stopped working.
• Pick a 6-week pilot period. Not "we are changing for good", but "we are trying something else for 6 weeks and then reassessing". That takes the edge off resistance to change.
• Keep one synchronisation ritual. Even without sprints, the team needs a regular slot to coordinate and align on priorities. The frequency can change; the need cannot.
• Measure what changes. Before and after: cycle time, team satisfaction (a simple 1-5 scale each week), number of blockers cleared within 24h. Without measurement, there is no way to know whether the transition worked.

Scrum is not a religion. It is a tool. And like any tool, how useful it is depends on the context you use it in. Real agility is knowing how to adapt — including adapting your own way of working.

If your team suffers from the framework more than it benefits from it, you have permission to change. You do not need a manifesto to justify it. You just need to look at what still produces value and what no longer does.