The Guide to Effective Agile Retrospectives

A retrospective is a structured moment for the team to stop, breathe, and reflect on the past cycle. The team meets to discuss what went well, what went less-than-great, and what could be better if the team has the energy to improve. In Scrum, the retrospective is usually the last activity in a Sprint.

Many teams struggle with retrospectives at first as they’re looking to score an early home run improvement. Later, they just want the activity to be over as fast as possible. “Just 3% better every Sprint” is what client Braden Box tells his teams they want to achieve. Curiously, if they do that consistently every two-week Sprint throughout a year, they will be more than twice as good at the end (1.03 ^ 24 == 2.03). In reality, teams will show remarkable improvement in some Sprints and not so much in others, however the power of small, compounding improvements is at the heart of what we’re looking for.

Too many teams conduct their retrospective and agree on a fuzzy, general statement, like “We should write more Unit Tests” or “We should automate some tests,” without a common understanding of a) the goal, b) an action plan, and c) a way to measure success. These teams also tend to lack a way to visualize progress towards their goals, which makes sense because if you’re not clear on where you’re going, how do you know how far you’ve come? With all this vagueness, it isn’t surprising when they struggle to achieve anything beyond the most basic improvements that can be achieved by a single heroic team member.

It’s often assumed that all improvements will work – it says so right in their name, right? In fact, that’s unlikely. Instead, all “improvements” should be seen as experiments. Some experiments clearly improve the system, and you want to keep those. Some fail and you use those to seed the next experiment, which will be better calibrated to bring the results you hoped for. The trick is to view each experiment as an improvement in the process, which will ultimately bring you improvement on a larger scale. Use experiments to apply an improvement, that either succeeds or fails, so you can learn from that quickly and adjust accordingly.

Many retrospective anti-patterns occur because the team doesn’t have a fundamental understanding of retrospectives. They see them as a necessary evil, rather than the opportunity to reflect and improve.

All Talk, No Action

There are many reasons for this problem. Some teams just use retrospectives as casual discussion time, others create actions but they’re wishy-washy and ill-defined, some create actions but then never act on them, and others are too heads-down busy on Product Backlog Items to have time for that, or so it seems. In most of these cases, the challenge appears to be around creating and taking actions, and time pressure concerns.

Solution: Ensure that the retrospective has enough structure so that the team doesn’t stay stuck in discussion forever. Remember, some discussion is good, but not when it’s never-ending. Make time to refine improvements from fuzzy goals into concrete actions or experiments. Ask for volunteer experiment owners, track their progress through the Sprint, and ensure that you review the experiment outcomes with the team in the next retrospective. The time pressure is never going to go away, so we have to build in time specifically for making improvements during the Sprint, even if it’s only small increments.

Perennial Problems

In teams that take no action, or whose actions are ineffective, problems become permanent. It might seem like an issue has been resolved, but then it pops up again and again, like a bad weed. When that happens, we move from the mode of attempting to run experiments to the mode of “well, that’s just the way things are done around here.”

Solution: It’s best nipped in the bud before it becomes a bigger problem. If the team has already reached that stage, look for the smallest problem that the team could seek improvement on and improve there. The goal is to help the team regain its confidence or mojo with small wins.

ScrumMaster Hero

One of the few things most people “know” about Scrum, is that the ScrumMaster removes impediments. Therefore, they assume the ScrumMaster gets assigned all improvements. Or maybe a senior developer enjoys the heroic status of solving problems for the team. Since some people don’t enjoy improvement work, they’re happy to sit back and have someone else take the reins.

Solution: Contrary to popular belief, the ScrumMaster isn’t required to do all of the heavy lifting. Instead, they’re responsible for seeing that the problems get solved. Remind team members that when someone steps up, that means that they’re volunteering to shepherd the solution, not solve the problem themselves. If the person who does volunteer seems nervous, privately offer to coach them.

The full guide covers eight more anti-patterns, plus the challenges facilitators meet most often: the Dominator, the Non-Participator, and the team that doesn’t want retrospectives at all.