How to structure an agile retrospective

Have you ever been in a retro which has quickly descended into rambling conversation, or worse, a "whinge fest" where lots of grievances get aired but without a constructive way forward. Everyone leaves feeling like things are a bit rubbish, feeling better for having got it off their chest, but downtrodden that there doesn't seem to be a way forward. 

We can help our agile teams generate actionable insight in retrospectives by providing structure to our retrospective that maximise the chances of teams being able to make positive changes to their working processes and practices. 

The following framework for running a structured retrospective is outlined in the book Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. 

1. Set the stage
2. Gather the data
3. Generate ideas
4. Decide what to do

1. Set the Stage (5 - 20 minutes)

The first stage is about getting everyone into the right mental place to constructively reflect on the past sprint or iteration. If you can do something fun, or something that's likely to make people smile, even better. A bit of levity early on can bring people's guard down, and make it more likely that they'll talk about any issues the team are encountering that they might.

A key point here is that we should aim to let everyone on the team say something in the first 5-10 minutes. Even if it's only a single word, getting everyone to say something early on sets the stage for further conversation. When participants don't do this, they tend to feel like they have permission to remain silent, and can be reluctant to contribute in other ways.

An example starter exercise: Mood by Masterpiece

2. Gather the data (15 - 30 minutes)

The second stage is about giving the team an opportunity to reflect on the past sprint. 

The goal here is to collect everyone's thoughts and perspectives on what is going well, what is slowing the team down or getting in the way.

A good way to do this is to give everyone sticky notes to capture their thoughts. Once people have captured their reflections, ask the team to move sticky notes around the board so that they are grouped with other sticky notes that essentially say the same thing. Then give everyone sticky dots, and ask them to vote for what they think is the most important issue for the team at the moment.

For an alternative way to gather data, see this post about how to help your team improve sprint meetings

3. Generate ideas (15 - 30 minutes)

The team have identified what they think are the most important issues facing them at the moment. Now it's time to generate ideas for how we can improve and make things better.

At the simplest level, this might involve a discussion. For example, if people have voted to discuss an issue around there not being enough time in the sprint to finish testing, you could ask the person / people who wrote that post-it note to "say a bit more about what's on your mind". Once they've described the issue in more detail, ask the team if anyone has any ideas about how they could solve the problem. 

Alternatively, ask the team to split into smaller groups to come up with ideas about what they could do to improve or solve the problem.

Capture the ideas as they are generated on the team on post-it notes.

In Agile Retrospectives: Making Good Teams Great, Esther Derby and Diana Larsen talk about encouraging the team to generate several potential solutions before choosing one to move forward with. This is because when we have a problem but no solution, we are in a state of uncertainty. In this state of uncertainty, we crave a way forward and our minds are quick to jump on any plausible solution. However, the first plausible solution we hit upon, may not be the one best suited to our particular situation.  

For an alternative way to generate ideas, see this post about how to help your team improve sprint meetings

4. Decide what to do (15 - 30 minutes)

Once a few ideas have been generated, ask the team to vote on which option they would like to pursue further. 

You can then discuss what next steps are needed to but this into the practice. Ideally, someone on the team should be assigned to carry out the action, and be prepared to report back in the next retrospective.

It's important to emphasise the importance of experimentation in agile, encouraging teams to be bold, test hypotheses and try out new approaches. Even if it doesn't work out, we will have learnt more from the experiment than from making little tweaks here and there. 

After the retrospective is finished, circulate minutes from the meeting summarising what has been discussed, and what actions we have agreed upon as a team.