Where retrospectives go wrong

Retrospectives are meant to be a time for a team to look back at their work and learn. That idea was formalized in software by Norman Kerth’s 2001 book, which laid out a method for preserving lessons from both success and failure. Later, Larsen and Derby’s Agile Retrospectives adapted the practice into shorter sessions that fit agile rhythms, with the promise of making good teams great — not just rescuing failing ones.

But the wider adoption of agile methods turned retrospectives into a routine obligation. Many teams run them without learning how to facilitate them properly, and the result is sessions that feel like a waste of time. Three common failure patterns stand out: jumping to conclusions without examining the real problem, spending effort on issues that are outside the team’s control, and letting one dominant voice drown out everyone else.

Fast solutions, slow symptoms

A Danish organization introduced retrospectives as part of its agile transformation, but team members viewed the 90-minute sessions as an interruption to their “real” work. They pressed the facilitator to shorten them. Eager to comply, she cut back until the time was barely usable, triggering an antipattern called Wheel of Fortune — an environment where outcomes are random because the team never actually diagnoses anything.

Rushing led the facilitator to skip the insight stage. She used the “Start, Stop, Continue” activity, put up three posters, and asked the team to write notes. Within 20 minutes they had their action items: three hours of pair programming three days a week, and no meetings on Wednesdays or after lunch.

This works only if the post-its represent root causes rather than symptoms. The original reason pair programming wasn’t happening might not have been a lack of scheduling but insufficient psychological safety. In that case, pushing the activity into the calendar makes people more uncomfortable — or drives them away. For remote teams, the problem could be a missing skill in doing pair work apart from each other, which a schedule change doesn’t fix. Likewise, a complaint about too many meetings is often a complaint about meeting quality, and cutting quantity only hides the issue. Better meeting hygiene would address what actually bothers the team.

Skipping the insight stage means the underlying problems stay alive and reintroduce themselves regularly. To refactor this pattern, the team should deliberately generate insights before proposing action points. Simple discussion works, as does a “5 whys” interview. A problem like “we missed the deadline” or “we didn’t follow the peer review process” sounds straightforward but can have many distinct causes; a fishbone analysis is suited to such cases.

Stuck in things you can’t fix

The same team showed another pattern later when they devoted a retrospective to vendors delivering poor software, a frustration that had come up many times before. Escalation to management had done nothing, and each discussion left team members angry and sad. Because nothing was actionable, the session achieved nothing — the In the Soup antipattern.

Time spent on a problem the team cannot change is time taken away from problems they can. The refactoring borrows the name of the antipattern and asks participants to sort their concerns into three buckets; things they can do something about, things they can influence, and things that are simply in the soup. The last category is part of life that no amount of discussion will alter. The best use of that energy is to accept the constraint, adapt, or remove yourself from the situation entirely. This filter is useful right after data gathering, and again when choosing action points, so no one leaves committed to work that is outside their authority.

One voice, many listeners

A Loudmouth can shut down a retrospective even when the other practices are sound. In plenary discussion, one person interrupts and tells lengthy stories, and the facilitator’s direct invitations for others to speak change nothing.

The harm is not in having something to say; it is that a retrospective is a moment for the whole team to share, appreciate, and learn together. If only part of the team can participate, part of the time is wasted. The solution is to design the session around smaller interactions: split people into groups of two or three, have them write notes and move post-its instead of talking at large. It also helps to privately inform the loudmouth of the effect they have. Often they have no idea. People who are active thinkers use speaking as a way to process, and they need room to do that — but they benefit from learning how it comes across. As it happens, the quieter participants also thrive under these structural shifts, which are less daunting than a free-for-all discussion.

The most valuable facilitator skill is not a large repertoire of activity templates. It is the ability to listen, de-escalate tension, and keep learning what works for a particular team — then adjust before the next session runs off the rails.

Why Retrospectives Fail

Most retrospectives don't fail because the team lacks good intentions. They fail because of recurring behavioral patterns that facilitators unknowingly reinforce. These are the antipatterns I catalogued after more than 15 years of facilitating retrospectives and 20 years of teaching in academia and industry. My research into how people learn computer science kept surfacing the same lessons: some facilitation techniques work, and some actively work against you.

Recognizing the Patterns

Every antipattern has a name and a picture — the octopus appears often, because I love octopuses. The point of naming and visualizing these patterns is simple: you cannot fix a problem you cannot name. When a facilitator recognizes that they are in the middle of a known antipattern, they can recover quickly instead of letting the session spiral.

The Loudmouth

The classic version of this antipattern is the participant who dominates the conversation. The less obvious version is the quiet participant who never speaks. Funnily enough, the suggestions for handling a Loudmouth work with very quiet people as well. The fix is not about silencing someone; it is about changing the structure of participation so that everyone has equal space to contribute.

Practical Recovery

For each antipattern, the practical question is: what do you do in the moment? The answer is usually not a scripted intervention but a structural adjustment to the retrospective format. If one person is dominating, change the format so that people write ideas individually before discussing them. If the team is stuck in solution mode and skipping over problem analysis, insert a forced step that separates the two phases. These are small moves, but they shift the group dynamic without requiring confrontation.

Further Reading

For a deeper treatment, my book Retrospectives Antipatterns covers 23 common challenges with facilitation. Each chapter describes the challenge, offers practical ideas for overcoming it, and includes a personal anecdote from a time when I found myself in that exact antipattern. The content draws on more than 15 years of facilitating retrospectives, combined with insights from over 20 years of teaching — the overlap is where the most useful lessons live.