Scrum Anti-Patterns: The Signs Your Process Is Broken

An anti-pattern is a recurring practice that appears to solve a problem but consistently produces worse outcomes than the alternatives it displaced. The concept was introduced in software engineering but applies with particular force to process frameworks like Scrum. Scrum is deliberately simple — three roles, five events, three artefacts — precisely because simplicity makes anti-patterns visible. When a team adds roles, skips events, or hollows out artefacts, the deviation is structurally legible. The challenge is that the teams most embedded in anti-patterns are often the least able to recognise them, because the deviations have been normalised through repetition.

Six common Scrum anti-patterns

1. Zombie Scrum. The team goes through the motions of Scrum — Daily Scrums are held, Sprints complete, Retrospectives are scheduled — but there is no real collaboration, no genuine improvement, and no meaningful connection between the team's work and the outcomes stakeholders care about. Zombie Scrum is diagnosable by three symptoms: the Daily Scrum is a status report to the Scrum Master rather than a coordination conversation among peers; Retrospective action items are never implemented; and the team cannot explain how their current Sprint contributes to the product goal. The cause is usually a lack of psychological safety combined with insufficient stakeholder engagement — the team has learned that surfacing real impediments has no positive consequence.

2. The Hero Developer. One team member — typically the most technically capable — carries a disproportionate share of the Sprint. They resolve the blockers others cannot, they complete the stories that fall behind, and the Sprint velocity depends on their availability. This looks like a performance problem in other team members but is actually a systems problem: the Hero is being rewarded for behaviour that prevents the team from developing shared capability. The team never builds the collective knowledge to operate without the Hero, and the Hero burns out.

3. Sprint planning theatre. The team commits to a Sprint plan without a shared understanding of what that commitment means. Stories are accepted into the Sprint without genuine task decomposition or effort estimation. The "commitment" is social — nobody wants to be the person who says the plan is not achievable. The Sprint then proceeds exactly as the sceptics feared: stories spill into the next Sprint, the Definition of Done is quietly relaxed, and the review presents incomplete work as finished.

4. Retrospectives without action. The team meets, conversations are honest, improvement ideas are generated — and nothing changes. The failure mode is almost always the same: action items from the Retrospective are not assigned, not tracked, and not reviewed at the following Retrospective. After two or three cycles of this, the team stops surfacing real issues in the Retrospective because they have learned that surfacing an issue and addressing it are two unrelated events. The fix is structural: the first item on every Retrospective agenda should be a review of last Retrospective's action items.

5. Stakeholder capture of the Sprint. Stakeholders bypass the Product Owner and assign work directly to developers during the Sprint. The Sprint becomes a queue of ad hoc requests competing with committed Sprint backlog items. This directly undermines the Sprint's function as a protected container for focused delivery. It is almost always a symptom of a Product Owner who lacks the authority or the stakeholder relationships to defend the Sprint from external interference — and that is usually an organisational problem, not a personal one.

6. The Product Owner who cannot prioritise. Every backlog item is marked urgent. The Product Owner cannot make trade-offs because they are managing upward rather than downward — saying yes to stakeholders and passing the resulting impossibility down to the team. The backlog becomes unmaintainable, Sprint Planning loses meaning because there is no clear order, and the team loses confidence in the direction they are building toward. A Product Owner who cannot prioritise is usually suffering from insufficient authority rather than insufficient skill — the organisation has not given them the mandate to make binding decisions about product direction.

Diagnosing and recovering from anti-patterns

Anti-patterns are sticky. They persist because they represent an equilibrium — however dysfunctional — that the team and its stakeholders have adapted to. Recovery requires naming the anti-pattern explicitly, which is a diagnostic act that feels uncomfortable because it implies the current approach is not working. The Scrum Master's role is to create the conditions in which the team can examine its own process honestly and make the changes needed. That requires both the tools to diagnose anti-patterns and the relational capital to raise them without triggering defensiveness. The best diagnostic question a Scrum Master can ask is: "If this is the process we are running, what outcomes should we expect — and are those the outcomes we are getting?"

If your Scrum process is producing the right ceremonies but not the right results, XNM's program and project delivery advisory can help your teams diagnose what is not working and build the practices that make Scrum actually deliver.