How to run a retrospective

This post provides an introduction to team retrospectives and a guide on how to run them.

Intro to retrospectives

What is a retrospective?

A regular meeting for the team to reflect on past performance and identify ways to improve.

Why bother?

Good teams continuously improve their product. Great teams also continuously improve how they work together as a team.

Retrospectives help teams:

• Identify actionable ways to improve
• Make continuous improvement a habit
• Take collective ownership of their processes and ways of working
• Recognise each other’s achievements
• Celebrate good performance

Good retrospetives are:

• actions focused
• done frequently enough so that small gains add up to big wins
• not just for figuring out how to improve – also good to celebrate success or thank each other

When to do a retrospective?

I like to do retrospectives on a regular cadence so that they become a habit. Generally, I do a retrospective every 2-3 weeks but other options include:

• At the end of each feature
• At the end of each iteration
• After a milestone
• After an incident

How to decide a frequency? Start with any of the above, and allow the team to use retrospectives to change the frequency.

Where to hold a retrospective?

The team must feel safe to speak up, so it’s important to hold the event somewhere where they won’t get overheard. If in the office, this is one you want to have a meeting room for.

Who should take part?

All members of the team should participate.

People outside the team should usually not attend unless the team are comfortable with their presence.

How to run a retrospective

There are lots of ways to run a retrospective. These are some suggestions of things that have worked for me in the past. For other ideas, check out:

• Agile retrospective resource wiki
• Retromat – plans for retrospectives

Start with the prime directive

The purpose of a retrospective is to figure out how to improve, not who to blame.

One of the biggest fears people have about retrospectives is that there will be lots of finger-pointing. An event like this will not do little to help the team learn and improve. The team need to feel psychologically safe, or they won’t be able to talk openly about problems.

Norm Kerth’s Retrospective Prime Directive helps set the tone for a good retrospective. It is:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Make sure everyone in the team understands this. You might want to read it out at the beginning or stick a copy up on the wall. Definitely do this if your team are new to retrospectives or prone to unhealthy conflict.

You will need…

If you’re in the office then you will need:

• A room/space where the team can speak in private
• Post its & pens for everyone
• A stopwatch and clock for the facilitator
• A copy of the prime directive on the wall

If remote, then you’ll need access to an online tool. Trello, Miro, Notion and Whimsical are all tools I’ve used to run retrospectives before. I suggest using a tool your team know how to use.

For the instructions below, I’ll assume you are running the retrospective in person. It should be easy enough to adapt to an online tool though.

Step 1. Put the categories up on the wall

My default categories are: “Good, bad, change, thanks”

Others I’ve seen work well include

• “Start doing, stop doing, do more, do less”
• “Liked, learned, lacked, longed for”

The categories are only there to get ideas out of team members’ heads. So don’t worry too much about which categories to use, or if people add things to the wrong category.

Step 2. Introductions

For teams that are new to retrospectives, take time to explain

• what a retro is, why you are doing it & the prime directive (all covered above)
• the scope of the retrospective (what specific time period/process/project phase to focus on?)
• the structure of the session

Step 3. Review previous actions

If there are any actions from a previous retrospective, review them at or before this stage.

If an action isn’t done, allow the team to decide whether to keep it as an action. I suggest asking people for a simple thumbs up / thumbs down and following the majority.

Step 4. Gather feedback

Allow each team member 3-5 minutes to write down their thoughts & observations. Once the time is up, each person should take turns adding their post-its to the wall. Everyone should briefly explain what their feedback is before adding it. Some teams start by reviewing important events from the past iteration to jog people’s memories.

If doing a retrospective on a specific topic (eg. deployment process), stick the process up on the wall.

Step 5. Group and prioritise

Allow everyone to vote on the issues they want to discuss by drawing a dot on the post-it. Dot voting is a very effective way of democratically running a meeting.

Some rules I often use with dot voting:

• limit people to 5 votes each to make them prioritise
• only allow people to place 1 vote per card to avoid someone voting for one card 5 times

As people are voting, group post-its if they are about the same issue. Some people do this as they are adding post-its to the wall, in which case this shouldn’t take long.

Once everyone finishes, count up all the votes. Find a way of visualising them in order with the most voted at the top. I usually write the number somewhere prominent on each cluster of post-its. Sometimes I will create a separate ordered list.

Step 6. Discuss & Agree Actions

Now we are ready to discuss the actions. A good rule of thumb is that the team should aim to spend about half the retrospective focussed on discussing actions.

Discuss each card in priority order, and identify actions for each

• Stay focused on actions. Try to keep them SMART
• Move on asap if it’s clear there will be no actions

Timebox the discussion on each card to 5 minutes

• If time runs out, take a quick vote on whether to extend by an extra 5 minutes or not

Actions should have owners

• Write their name in the corner of the post-it

Step 7. Follow up actions

After the retrospective, keep the actions visible to the team. Good places to keep retro actions are on a wall, in a team wiki, or in the team’s task-tracking tool.

If the team has a delivery manager or scrum master, they should check in with people after a week or so. This will reduce the likelihood of actions getting forgotten.

Tips for facilitators

Time guides

I estimate you will need

• 60 minutes for a team of 8
• 75-90 minutes for large or complex teams

I try to make sure at least half the allotted time is for discussion and agreeing actions.

If there is a single issue that is too big for the retro, consider arranging a separate workshop to focus on finding a solution.

Keep the discussion focused on actions

The key output you want from a retrospective is actions. The focus is on continuous learning and improvement.

Sometimes teams need to vent about something. This is often a very good thing for the team to do, but not for too long. Allow a little time for venting, but try to steer the team towards actions they can take to make the situation better.

Ask: “Are there any actions to take away here, or shall we move on to the next topic”.

Getting actions over the line

When someone suggests an action, I take the view that “silence = consensus”. I’ll add the action to the actions list, and invite other participants to object.

If there’s uncertainty, allow the debate to carry on for a brief period before taking a vote from the team to decide whether to keep the action or not.

Actions as experiments

Another good way of getting actions over the line is to position them as experiments. Try it out for a few weeks, then decide whether to continue or stop at the next retrospective.

Ensure everyone gets heard

If quiet people are struggling to get into the discussion, hold space for them and invite them in.

If people don’t want to speak up, try speaking to them after to see if you can coach them to contribute more.

Don’t worry if nobody prioritises discussing things that are going well

This is normal.

If you spend too long discussing things in the good column you are not doing it right.

Most of the actions usually focus on fixing things that aren’t working. So most of the discussion in the second half of the retrospective usually focuses on that.

Consider using a theme

Some teams like breaking up the monotony of retrospectives by theming each one. I remember my old manager Rosalyn Vaughan facilitating one with a Game of Thrones theme. The categories were:

• The Iron Throne (good things)
• Joffrey Baratheon (could’ve been better/nicer)
• You know nothing Jon Snow (things we learnt)
• Winter is coming (things we’re nervous about)

Easy Retro have a good directory of themes if this interests you.