Retrospective Anti-Patterns: Why Most Retros Fail and How to Fix Them

The retrospective has a reputation problem. Ask teams what they think of their sprint retrospectives and you'll hear versions of: "It's fine." "We go through the motions." "Same things come up every time." "I'm not sure anything actually changes."

This is not a problem with the retrospective as a concept. It's a problem with how retrospectives are typically run — a set of anti-patterns so common they've become normalised. Teams don't know they're failing because failing retrospectives look a lot like successful ones from the outside: people showed up, a format was followed, notes were taken.

Here are the ten anti-patterns that turn retrospectives from improvement engines into calendar overhead — and the specific fixes for each.

Anti-Pattern 1: The Eternal Recurrence

What it looks like: The same three issues appear in every retrospective. "We need better communication." "Requirements are unclear." "Too many interruptions." Sprint after Sprint. The team lists them, nods, and agrees to "work on it." Nothing changes.

Why it happens: The root cause was never found. The team is treating symptoms, not causes. "Better communication" is not an action — it's a category. Without a specific structural change (a new meeting, a new agreement, a new process), the issue will recur because the system producing it hasn't changed.

The fix: Apply the 5 Whys to any issue that has appeared more than twice. Ask why it keeps happening despite previous agreement to fix it. The answer usually reveals either: the previous action item was too vague, the root cause is outside the team's control, or there's a structural incentive maintaining the problem.

Once you find the actual cause, you can do something about it. Until then, you're rearranging deck chairs.

Anti-Pattern 2: The Action Item Graveyard

What it looks like: The retrospective ends with a list of action items. They're added to a Confluence page or a "retro actions" document. By the next retrospective, nobody can find the document. New actions are generated. The old ones are never completed or reviewed.

Why it happens: Actions stored separately from the team's working system are invisible in the team's working system. A Confluence page has no pull on behaviour. An item in the Sprint Backlog does.

The fix: Every retrospective action item goes directly into the Sprint Backlog as a story or task with an owner. It's treated like any other work the team is accountable for. At the start of every retrospective, the first agenda item is: review last retrospective's actions. Not new data — old actions. Were they done? If not, why? That's your first topic.

This single change — treating retro actions as real work — improves follow-through more than any format change.

Anti-Pattern 3: The Vague Action Item

What it looks like: The retrospective closes with action items like "improve code review," "communicate earlier," "be more proactive about blockers." These are intentions, not actions. Nobody knows what to do specifically, so nobody does anything.

Why it happens: Teams are often good at naming problems and poor at designing solutions. Moving from "the code review process is slow" to a specific, owned, measurable change requires more facilitation effort than most teams invest.

The fix: Every action item must pass a three-question test before the retro ends:

• What exactly will be different? (Describe the specific new behaviour or artefact)
• Who is responsible? (One person's name, not "the team")
• By when? (A specific date, not "next Sprint")

"Improve code review" becomes: "By Sprint 16 start, Jonas will create a PR review checklist with max 24-hour SLA, tested on three PRs before going live." That's an action item.

Anti-Pattern 4: The HiPPO Effect

What it looks like: The manager or most senior person in the room speaks first in the data-gathering phase. Their framing anchors everyone else's contributions. The quieter team members nod along. The retrospective reflects one person's experience of the Sprint, decorated with mild agreement from others.

Why it happens: Hierarchy creates psychological pressure even when nobody intends it. Research on group anchoring shows that people update their stated opinions significantly toward early contributions from high-status individuals, even when privately they disagree.

The fix: Run all data-gathering phases in writing first. Silent individual sticky notes before any verbal sharing. When contributions are anonymous or simultaneous, anchoring is significantly reduced. Consider using anonymous input tools (EasyRetro in anonymous mode, a pre-survey) when the power dynamic is significant.

Also useful: explicitly ask senior team members to go last in discussion rounds. Frame it as an invitation, not a rule: "I'd like to hear from everyone else first, then get your perspective."

Anti-Pattern 5: The Therapy Session Without the Therapist

What it looks like: The retrospective becomes a space for venting without resolution. People share frustrations (legitimate ones), they're validated, but nothing concrete is decided. The session feels cathartic but produces no structural change. The same frustrations return next Sprint.

Why it happens: Psychological safety enables honest emotional expression, which is genuinely valuable. But venting without accountability structures is just shared suffering. The format allows it because it doesn't have a clear transition from "express the problem" to "decide what to change."

The fix: Enforce the structure. After the data phase, name the transition: "We've heard a lot of important things. Now let's move from what happened to why it's happening, and then to what we're going to do." The insight phase and the action phase are not optional extras — they're where the retrospective's value is created.

Also: remind the team of the Retrospective Prime Directive before starting. It reframes the session from blame and frustration to inquiry and improvement.

Anti-Pattern 6: The Positive-Only Retrospective

What it looks like: Everything is fine. The team generates an enthusiastic list of what went well. The "what could improve" section is thin, polite, and uncontroversial. Action items are cosmetic. The Scrum Master leaves the room unsure whether the session was useful.

Why it happens: Psychological safety is low. Team members don't believe that honest feedback will be received without political consequence. Or the team is genuinely performing well but the format doesn't create the depth to find where 80% could become 90%.

The fix: Create safety explicitly. The Prime Directive is the minimum. Anonymous input is more powerful. A pre-retrospective individual survey (sent 24 hours before, anonymous) surfaces what people won't say in the room.

For high-performing teams where everything genuinely is going well: switch to more advanced formats. A Pre-Mortem forces the team to imagine failure rather than review success. A Working Agreements review finds what's drifted. Circles and Soup examines the boundary between what the team controls and what controls them.

Anti-Pattern 7: The Format Fossil

What it looks like: The team has run Start/Stop/Continue for 18 months. Everyone knows what's coming before it starts. Participation is mechanical. The sticky notes are similar to last Sprint's sticky notes. New team members get a blank stare when they ask why this particular format.

Why it happens: Comfort with a known format reduces the friction of running the session. The format became the goal rather than a vehicle for the goal.

The fix: Rotate formats every 3–4 Sprints. Keep a visible list of which formats you've used. Select the next format based on what the team needs now: emotional processing, systemic analysis, creative problem-solving, or accountability. The format change alone will generate new information from people who had stopped seeing the familiar format.

Anti-Pattern 8: Solving Problems Nobody Owns

What it looks like: Retro actions involve people or systems outside the team's control. "Engineering should fix the build pipeline." "Management needs to stop adding scope mid-Sprint." "The product team should communicate requirements earlier." These action items exist on paper. Nobody follows up. Nothing changes.

Why it happens: Teams correctly identify real problems caused by external factors. But the action items are assigned to people who weren't in the room and didn't agree to anything.

The fix: Use Circles and Soup to explicitly categorise problems by what the team controls, what the team can influence, and what's beyond their reach. For problems in the "influence" circle: the action is to escalate or advocate, with a specific person owning that escalation. For problems in the "soup" (beyond reach): name them, acknowledge them, and decide consciously not to generate action items about them.

This isn't resignation — it's precision. Energy spent on influenceable problems produces change. Energy spent on uninfluenceable ones doesn't.

Anti-Pattern 9: The Retrospective Without Data

What it looks like: The retrospective is run entirely from memory and feeling. Nobody looked at the Sprint metrics before the session. Sprint velocity, bug count, deployment frequency, support ticket volume — these exist somewhere, but they're not present in the room. The team reflects on a subjective impression of the Sprint, not the actual Sprint.

Why it happens: Gathering data feels like extra work before what's already a meeting. Scrum Masters default to the human conversation rather than the quantitative foundation.

The fix: Spend 10 minutes before the retro pulling 3–5 key metrics from the Sprint. Velocity vs. commitment. Number of bugs escaped to production. Number of carry-overs. Number of interrupts. Days blocked by external dependencies. These are not the whole picture, but they're the objective foundation that prevents retrospectives from running on collective memory alone, which is systematically optimistic.

Anti-Pattern 10: The Retrospective Without Consequences

What it looks like: The retrospective is a nice conversation. People leave feeling heard. Action items are polite and achievable. Nothing significant changes. Six months later, the team works almost identically to how it worked at the start.

Why it happens: This is the meta-anti-pattern. All the previous ones contribute to it. But the deepest cause is that the team doesn't believe the retrospective has real stakes. It's a ceremony, not a mechanism.

The fix: Make the retrospective visibly consequential. Present retro action completion rates to the team monthly. Celebrate when a retro action produces a measurable improvement. Escalate unresolved systemic issues formally. Treat retrospective improvement as a team performance dimension, not an optional nice-to-have.

The retrospective should be the meeting the team most looks forward to — not because it's easy, but because it's the meeting where things actually change. When it has that reputation, participation, honesty, and follow-through improve naturally.

---

The good news: every anti-pattern above has a structural fix. None of them require heroic effort or rare facilitation skills. They require deliberate design — of the format, the environment, the action tracking system, and the norms around honest conversation.

The teams that run effective retrospectives didn't find a magic format. They systematically removed the structural barriers to honest reflection and accountable action. That work compounds. Start it this Sprint.