Making Retros Work: Turning Reflection into Peak Performance
The retrospective (or “retro”) is a standard Agile team meeting held to reflect on how a sprint went and what improvements could be made. Its purpose is to help teams perform better over time.
Unfortunately, they’re often a fraught meeting.
Common complaints include that they feel forced and formulaic, that they devolve into venting about issues outside the team’s control, or that they descend into struggle sessions.
Teams under tight delivery pressure resent them. So do teams with weak psychological safety.
But the worst indictment a retro can receive is: nothing changes.
Despite this, they’re one of the most important practices an organization can have. Problems with retros do not stem from their fundamental purpose, but from how they’re implemented.
This article will explain how to address common complaints, restore trust and motivation in them, and maximize their effectiveness.
The primary cause of ineffective retros
Failing retros are caused by a lack of focus on outcomes.
The retro is not a ritual, and not an actual “ceremony” despite that common Agile terminology.
The retro is a tool, aimed at increasing team effectiveness over time.
That doesn’t mean the mere act of doing retros will assure that outcome, any more than going to the gym guarantees six-pack abs.
The problem with treating it as a ritual is that the act of performing it becomes the goal, focusing on actions rather than outcomes. This encourages rigidity in its format – with close adherence to Scrum orthodoxy viewed as a virtue by itself.
The retro thereby becomes performative rather than effective – a resource sink rather than a resource amplifier. This is where most frustration with it originates.
A better approach is to anchor on the desired outcome of maximum team effectiveness, and then treat the retro meeting as one possible means to that end – without strictly deferring to a prescribed retro format.
Returning to first principles
The retro is grounded in the concept of the OODA loop – i.e. continuously adjusting course towards maximum team performance.
In essence: We observe what needs improvement, we orient ourselves by identifying root causes and brainstorming solutions, we decide the improvement actions we will take, and then act on those decisions.
We repeat that ad infinitum.
That does not mean we must have a single formal retro meeting on a specific day every sprint, run for a specific time period, and carried out in a specific format.
In fact, as Boyd – the author of the OODA concept – pointed out, faster OODA loops produce better performance.
That is, the loop itself is an improvement target. Viewed through this lens, ritualism in retros is counter to improvement – because it prefers consistency over change.
In practice, fast OODA loops mean:
Observing continuously. Rather than waiting until the next retro to recall issues since the last one, write down observed problems in a central location the moment they are spotted.
Orient frequently. The team lead, scrum master, and team as a whole should not default to deferring problems to the next retro. They should prefer to take action on them immediately where appropriate.
Decide quickly. Fast and effective decision making is a manager’s primary responsibility.
Sometimes a problem is complex and best solved in a brainstorming meeting. But most of the time the solution is obvious and can be implemented immediately after soliciting input from the team.
Act diligently. Too many retros conclude with decisions that don’t get enacted.
Discussion is easy – especially when a mandatory time slot has been reserved for it. Making the changes is harder – it requires resourcing.
For this reason, action should be prioritized over additional observation and orientation.
Retro the retro. All of the above apply to the retro itself. If it's not working there is little point continuing it in its current form.
Troubleshooting retros
Under normal circumstances, all retros should feel useful and effective. They should not feel like a drag, not be fraught and tense, and not sound like a broken record each time.
Instead, retros should feel like a force for good, and retro workloads should steadily decline over time as delivery metrics improve.
If that pattern isn’t emerging, there’s a problem.
The following are techniques to troubleshoot those problems.
Same topics coming up each time
Instead of writing out each problem afresh each time, switch to gathering the issues into a persistent list. Put each issue into a ticket and then prioritize them – exactly the same as for feature tickets.
Then change the retro meeting’s agenda to reviewing that list and facilitating progress on it. That stops the meeting feeling ineffectual and wasteful – restoring trust. The ordinary format can be resumed once the situation is under control.
Retros running over and action items not getting created
Increase the team’s resource balance towards retros, usually by increasing the rate of retro meetings. If executed well this will be temporary.
It’s common for retro meetings in fraught teams to fill up a board with problems, only a fraction of which get discussed, and an even smaller fraction result in action items.
In this situation, don’t restart the board at the next retro. The agenda for the next retro is: agreeing on action items for the high impact items from the previous one, one at a time.
There’s no point filling up the “Observe” top of the funnel if it's clogged.
Action items not being completed
First, start every retro with a review of the previous retro’s action items. If any remain unfinished, that’s topic number one.
Second, put your action items into tickets and move them into the next sprint – now they have equal status to feature work.
If this results in pushback due to visibly reducing capacity for other work, ask your interlocutor which they’d prefer:
A temporary reduction in capacity to produce a permanent increase in capacity; or maximizing the amount of feature work that gets done this month, thereby minimizing the amount that gets done this year.
If the answer is biased towards the latter, that’s a time preference matter that your team has little influence over. It should be acknowledged, and factored into how your retros are structured.
If the organization will not permit engineering efficiency improvements to be resourced, there is little point spending time identifying them.
Controversial issues
Reduce the next retro meeting agenda to just solving that one problem.
Use the Double Diamond model to maximize the chances that the team hones in on the exact problem to be solved, and the best solution to solve it.
The team lead should give ample space for the team to work through this process. But if the team is genuinely unable to converge, the team lead needs to make an executive decision – reminding everyone it can be altered later if it doesn’t work.
Sparse issues
There are two main causes of a lack of retro items.
The first is there’s actually no issues worth discussing. The second is that people have given up on retros or have other reasons they don’t want to participate.
If the former, that’s fine, close the meeting early. It’s surprising how often the meeting organizer will instead try to drag the meeting out to fit into its allotted time box. Just end meetings when their agendas are complete.
If the latter, you have a trust issue. The retro now becomes a meta-retro: are there problems previous retros have failed to fix and why? Are there problems we’re afraid to discuss? Are we just tired of meetings? And so on.
Psychological safety is a prerequisite for effective retros. If people cannot raise issues or express disagreement without fear of reprisal, no retro format will work.
Another cause is people forgetting issues by the time retro rolls around.
It helps to create the next retro board at the end of each retro, so issues can be added as they arise during the sprint.
You can also run project retros. While Agile avoids the word “project”, epics often unfold like projects in practice, and running a retro right after it's been delivered allows a deeper reflection of the entire effort.
Repeated focus on external constraints
If the team feels that a recurring problem cannot be fixed because it has an external origin, and attempts to influence that origin have had little effect, continuing to vent frustration on that topic should be curtailed.
Instead, the team should document it as a known obstacle, accept that it is unlikely to change, and devise ways to work around it.
The team lead can continue to signal the issue upstream as appropriate, and the team can occasionally revisit the workarounds they have devised.
But if the topic reappears on the retro board, the meeting organizer should encourage the team to set it aside quickly.
Alternatives to scheduled retro meetings
The retro does not have to be done with a meeting.
For some difficult issues, it can make sense to raise them in a meeting with the full team. It’s also understandable to protect focus on sprint work by deferring reflection on problems until the end of the sprint.
But sometimes it’s more effective – especially once retro workloads have dropped – to raise problems as they’re encountered. Motivation to solve them is higher in the moment – and recollection is clearer.
This consideration is even more important in distributed teams, where it’s best to avoid using synchronous retro meetings where possible.
This means posting the issue on the team Slack, and letting anyone interested in solving it contribute possible solutions in the thread.
If the solution is obvious and accepted by everyone – which is common – someone can be delegated to apply it immediately.
Otherwise, the topic can be deferred to the next retro meeting, or someone can be delegated to research how others solve those issues and report back.
Using these asynchronous retro techniques can allow much faster OODA loops, resulting in quicker team performance improvements and plummeting retro workloads.
Conclusion
Constantly improving performance requires continuous inspection and adaptation.
Retros are the mechanism that enables this. When they are treated as outcome-focused tools rather than rituals, rising delivery speed follows.