"Retrospectives That Change Nothing"

December 2025 10 min read Opinion + Tool Review

The Retrospective is Scrum’s most powerful mechanism for organisational learning. It is also the ceremony most consistently reduced to a structured complaints session that produces action items nobody acts on. This is not a facilitation problem. It is a structural one.

---

The Hook: The Same Three Problems, Every Sprint

Here is a test. Find the retrospective notes from your team’s last six sprints. Look at the top three issues raised in each one. Count how many of those issues appear in more than three sprints.

In my experience, the answer is usually: most of them. The same communication problems, the same dependency issues, the same estimation challenges, the same inter-team friction – surfacing, being discussed, generating action items, and then resurfacing unchanged in the next retrospective. Month after month.

When the Retrospective is working, it is the engine of continuous improvement. When it is not working – when the same problems appear repeatedly without resolution – it is something worse than useless. It is a proof point that raising problems leads nowhere. Teams that learn this lesson stop raising real problems. They raise safe ones instead. The retrospective becomes a comfort ritual rather than a change mechanism.

---

The Reality: Why Retrospectives Stop Working

Root Cause 1: Action Items Without Owners or Deadlines

The most mechanical failure. The retrospective identifies five problems and generates five action items. Each action item is recorded in the team’s Confluence page or on a sticky note on the wall. Nobody is specifically accountable for any of them. There is no deadline. At the next retrospective, the Scrum Master reads them out. One has been partially addressed. Four have not been touched. Five new action items are generated.

This is not a retrospective problem. It is a follow-through problem being expressed through retrospectives. The fix is brutal in its simplicity: one action item per retrospective, maximum. One owner. A specific, measurable outcome. Reviewed at the start of the next retrospective before anything else is discussed.

Teams resist this because it feels like progress is being limited. In reality, five unactioned items produce less improvement than one completed one. The constraint forces prioritisation. Prioritisation forces accountability. Accountability produces change.

Root Cause 2: The Team Has No Authority to Fix the Problem

This is the structural problem the title refers to. Many of the issues that surface in retrospectives are not within the team’s authority to resolve. They involve other teams, other departments, management decisions, organisational policies, or resource constraints. The team can identify them, discuss them, and generate action items for them. They cannot resolve them.

When a team repeatedly raises an impediment that requires organisational authority to resolve, and that impediment repeatedly goes unresolved, one of two things is happening: either the impediment is not being escalated effectively, or it is being escalated and being ignored. Both are damaging. The first is a Scrum Master problem. The second is an organisational problem that no retrospective format can address.

The authority diagnostic: Categorise your last ten retrospective action items. How many were within the team’s direct authority to resolve? How many required action from someone outside the team? For the external ones – what happened? If the pattern is “raised, noted, unresolved” – your retrospective is identifying organisational impediments that your organisation is choosing not to address. That is not a retrospective problem.

Root Cause 3: Psychological Safety Is Insufficient

Teams discuss safe problems in retrospectives and keep the real problems private. The real problems involve interpersonal conflict, performance concerns, management behaviour, or organisational dysfunction that feels too risky to raise in a group setting. The retrospective produces a tidy list of process improvements while the actual sources of team dysfunction remain unaddressed.

This is the hardest root cause to address because it requires something that cannot be created by a facilitation technique: a genuine belief that raising difficult issues will lead to productive outcomes rather than personal consequences. That belief is built over time through consistent, demonstrated leadership behaviour – not through ground rules written on a whiteboard at the start of a retrospective.

Root Cause 4: Format Fetishism

The Agile retrospective industry has produced an extraordinary variety of formats. Sailboat, starfish, 4Ls (Liked, Learned, Lacked, Longed For), timeline, happiness radar, DAKI (Drop, Add, Keep, Improve), Speed Car, Hot Air Balloon. Scrum Masters rotate through these formats in search of the one that will produce better outcomes.

The format is not the problem. I have seen the most basic Start/Stop/Continue format produce profound team conversations. I have seen elaborate, beautifully facilitated sailboat retrospectives produce nothing of substance. The format creates the container. What fills it depends on the team’s psychological safety, the facilitator’s skill, and – most importantly – whether previous retrospective outputs have actually produced change.

Teams that have learned that retrospectives do not change anything will not be reengaged by a new format. They will go through the motions of the new format with the same level of genuine investment they brought to the previous ones.

“A retrospective is only as powerful as the organisation’s willingness to act on what it produces. Without that willingness, the most sophisticated retrospective format is an elaborate way of wasting time.” Markus – agile-checksum.com

---

The Checksum: What the Scrum Guide Says – and What It Does Not

The Scrum Guide describes the Retrospective’s purpose clearly: to inspect how the last Sprint went with regard to individuals, interactions, processes, tools, and their Definition of Done, and to identify the most important improvements.

Two words in that description are worth emphasising: most important. Not all improvements. The most important ones. The Scrum Guide is implicitly acknowledging that a team cannot improve everything simultaneously. It is asking teams to prioritise their improvement efforts – to identify the one or two changes that will have the greatest impact and focus on those.

Most retrospectives do the opposite. They generate comprehensive lists of everything that could be better and then fail to act on any of it because there is too much to act on and no clear priority among the items.

What Good Retrospective Output Looks Like

Effective Retrospective Output	Ineffective Retrospective Output
One or two specific, actionable improvements	Five to ten action items of varying specificity
Named owner for each action item	”The team” as owner
Clear definition of what “done” looks like for the action	Vague action items open to interpretation
Review at the start of the next retrospective, first item	Review sometimes happens, sometimes does not
Escalation plan for items outside team authority	Items outside team authority noted and forgotten

---

Real-World Examples

The Forty-Seven Action Items

Earlier in this blog I mentioned a team with forty-seven retrospective action items accumulated over twelve months, six of which had been completed. That team is worth returning to here because the diagnosis was illuminating.

When I reviewed the action items in detail, I found three categories. The first category – about 30% – were items the team had genuine authority to address and had simply not prioritised. The second category – about 50% – required action from someone outside the team: a dependency resolution, a management decision, a process change in another department. The third category – about 20% – were items so vague that nobody could have actioned them. “Improve communication” appeared four times.

The team had been generating action items without distinguishing between these categories. They were treating “we identified the problem” as equivalent to “we are addressing the problem.” They were not. The retrospective had become a documentation exercise rather than a change mechanism.

The Retrospective That Changed Everything

I want to include one example of a retrospective working as intended, because the pattern is instructive.

A team I coached had been struggling with a persistent quality problem – a high rate of bugs reaching production despite having a Definition of Done that included testing requirements. The problem had been raised in three consecutive retrospectives. Action items had been generated. Nothing had changed.

In the fourth retrospective, I changed the approach. Instead of generating action items, we spent the entire session doing root cause analysis on a single specific example: a bug that had reached production two sprints earlier, tracing backwards through every decision and process step that had allowed it to happen. We used a five-whys approach and followed the thread wherever it led.

What we found was not what anyone expected. The bug had reached production not because of inadequate testing, but because a developer had marked a story as done under time pressure at the end of a sprint, knowing that one of the Definition of Done criteria had not been met. He had done this because the team had consistently over-committed in Sprint Planning and he had felt unable to raise the concern without appearing to be the bottleneck.

The root cause was not a testing problem. It was a psychological safety problem manifesting as a quality problem. The fix required two conversations: one with the team about over-commitment in Sprint Planning, and one with the Scrum Master about creating space for concerns to be raised without consequences. The Definition of Done was not changed. The behaviour around it was.

That retrospective took ninety minutes and produced two action items, both with named owners and specific outcomes. Both were completed within the following sprint. The bug rate dropped by 60% over the next two months.

---

A Tool Review: What Actually Helps

Since this article is categorised as Opinion + Tool Review, here is an honest assessment of the retrospective tools and approaches I have seen work – and not work.

What Works

• Five Whys: Powerful for genuine root cause analysis on specific, concrete problems. Requires a skilled facilitator to prevent it becoming circular. Not suitable for every retrospective – use it when you have a persistent problem that surface-level discussion has not resolved.
• Pre-mortem: Imagining that the next sprint has failed catastrophically and working backwards to identify what caused it. Excellent for surfacing concerns that team members are reluctant to raise directly. Creates psychological distance from the actual team dynamic.
• Team health checks: Regular, lightweight assessments of team health dimensions – clarity, trust, collaboration, learning. Useful for tracking trends over time rather than identifying specific actions. The Spotify Squad Health Check model is a reasonable starting point.

What Does Not Work (As Promised)

• Rotating formats for their own sake: If the team is not engaged, a new format will not fix it. Address the engagement problem first.
• Anonymous input tools: Useful for surfaces where psychological safety is genuinely low. Not a substitute for addressing the psychological safety problem itself. If your team can only be honest when anonymous, you have a culture problem that anonymity is masking rather than fixing.
• Happiness metrics as primary output: “The team rated their happiness as 3.2 out of 5 this sprint, down from 3.6.” This is a lagging indicator of something. What that something is requires investigation. Do not mistake measurement for insight.

---

The Takeaway: The Retrospective Is a Mirror and a Contract

The Retrospective does two things simultaneously. It reflects the team’s current reality – their relationships, their processes, their level of trust with each other and with the organisation. And it creates a contract: a commitment to specific changes that will make the next sprint better than the last.

When it stops being a contract – when action items are generated and not acted upon, when the same problems surface repeatedly without resolution – it stops being a Retrospective. It becomes a scheduled disappointment that teaches teams that raising problems leads nowhere.

Run the checksum on your Retrospective:

1. Name one concrete change in your team’s working practices that resulted directly from a retrospective in the last three months.
2. Of the retrospective action items from your last five sprints – what percentage have been completed?
3. Are the problems discussed in your retrospectives getting smaller over time, or are the same fundamental issues recurring?

If the problems are recurring, the retrospective is not failing. It is accurately reporting that the organisation is not changing. Those are different problems with different solutions.

---

Glossary Terms Used in This Article

• Retrospective – A Scrum ceremony for inspecting how the sprint went and identifying the most important improvements.
• Psychological Safety – The shared belief that it is safe to take interpersonal risks within a team.
• Definition of Done – The shared agreement on what “complete” means for a product increment.
• Scrum Master – The Scrum accountability responsible for establishing Scrum and serving the team.
• Sprint – A fixed time-box of 1-4 weeks in which a Scrum team delivers a potentially releasable increment.