How to run an effective retrospective

Team retrospective doesn't need fancy formats or activities. It needs to help the team improve. Here's how I run it as an engineering manager

How to run an effective retrospective

Team retrospective is one of the best tools in my toolkit as a manager, but it's often misused. I've seen retrospectives done just because the teams follow Scrum, without understanding the real value of this activity. In this article I explain what's the point of team retrospective, how to make most of it, and I present agenda I follow during retros I run.

I cover this topic in my last video as well, you can watch it below:

What's the point

The main point of retrospective is improvement. Retrospective allows people to introduce new ideas and point out problems, so that the team can improve their work. Without improvement, the retrospective is a waste of time. This is the most common mistake I see and it quickly leads to people becoming disappointed and disengaged.

Here's how it often goes: the team manager learns about this thing called retrospective from some article about Agile or Scrum, and decides to try it out. They organize a meeting and hype everyone about it saying "I'm there to listen to your ideas, let's make our work better! Agile, yeah!". So the team comes all excited, everyone points out some problems, brings some fresh ideas. The manager nods along, takes a photo of the wall full of post-it notes, in the end says "great meeting, very productive, we're Agile!", and then... nothing happens. A few weeks later the team comes to the retrospective meeting again, but there are fewer ideas and some of the problems mentioned sound famililar. By the time the next retro comes everyone figures out that literally nothing has changed, so they stop pointing out problems, and suggesting anything. The retrospective becomes yet another meeting that people hate to attend.

Sounds familiar? I've seen this happening many times, and sadly I also made this mistake as a manager. Over time I learned that in the key to a successful retrospective is the work that is done between one retro and another. Retro allows the team to align on what needs to change, but it does not change anything.

A recipe for good retrospective

Over time I came with a process that works quite well for me and the teams I've been managing. My goal is to keep the team motivated, and I have 3 principles that I follow as part of the process:

  1. Always improve – every month (we do monthly retros) we implement at least one improvement. Usually we manage to do better, but every time I ensure there's at least one action item that gets completed, no matter how small it is.
  2. Stay realistic – if something can't be changed, we acknowledge it, and move on. We don't make promises we can't keep.
  3. Everyone participates – as a manager I'm often tempted to take more than I can handle. It regularly led me to failing my commitments, so now I ensure that action items are distributed among the whole team.

With these 3 principles in mind, I have a routine that I follow. Below I explain how I prepare the meeting, what tools I use, and how I keep people engaged. Note: this is what works for me and my team. You can use it as a starting point, but don't follow it blindly. Always get feedback from your team and iterate.

Preparation

Most of these steps require some time only the first time, and they can be revised in the future, so don't overthink them, don't spend too much time on them.

Frequency

If you organize retro too rarely, people will only comment on the recent problems. If you organize it too often, you'll struggle to show a meaningful improvement from one retrospective to another. I usually run retrospective once a month and I find that working quite well.

Time

Do retro towards the end of something – a month, a quarter, a sprint, a project, anything. Make it easy for people to understand what period of time they should think of. Time of the day matters if you have a team distributed across timezones, but otherwise find something that you won't have to reschedule due to other meetings. I usually do it towards the end of the month, e.g. every last Thursday of the month.

Duration

Start with 90 minutes, this should be enough. The first retro might feel pretty long, as people have a lot of things to suggest and discuss, but the next meetings will be shorter. It depends on the size of your team, how chatty people are in general, but you can always limit the number of things being discussed. Don't go over 2h, it's exhausting.

Note taking tool

Pick some digital tool. Even if your team is in the office and you use post-it notes, you'll need to digitize them. Make sure everyone can collaborate on the notes at the same time. You can start with something as simple as Google doc, though there are dedicated retro apps out there. I currently use GoRetro, which I can recommend - it's not the fanciest tool, but it does the job, and a few bugs that I reported via their chat were fixed within 2 weeks.

GoRetro, a tool I usually use for retrospective (image taken from goretro.ai)

Retro format

When collecting ideas you need to decide how you're going to organize them. An example is "Mad-Sad-Glad" where items are added into 3 categories: what made people mad, what made them sad, and what they're glad about. There are tons of other formats that you can try, though I've noticed that a lot of them are confusing and don't add any value. I choose the simplest one I know: what "went well" and what "to improve". I also add a 3rd column to later put action items.

Note: the more fancy retro formats don't necessarily make the team better. Some of them are confusing, and some ask the wrong question. A popular "what should we stop/start/continue" format asks for solutions: "what should we stop doing?". Instead, it should ask for a problem "what didn't work well?". Once you know what didn't work well, then you can look for a solution and ask "what are we going to do about it?".

The meeting

During the meeting I have a following agenda:

  • review past action items (5min)
  • write down thoughts (10min)
  • discuss the cards and vote (15min)
  • talk about solutions and agree on new action items (20min)
  • select action items to focus on and assign them (5min)

We usually start the actual meeting 5min past agreed time, so the whole thing takes us 1 hour. Here's what's happening in each part.

Review past action items (5min)

We start by looking at the action items from the past retrospectives. I keep them in one place and regularly update their status (I write more about it in the "post meeting" part of the article). This part is extremely important, because it shows the progress we're making month over month. It takes just a few minutes, but it sets the right mood. And it keeps me at check: in the end I'm accountable for my team's success, so I ensure that every month we do actually make progress.

Write down thoughts (10min)

In the next part we populate the "went well" and "to improve" columns. Everyone can write down as many cards as they want. This part might take longer, but usually everyone thinks about the retro before the meeting, so we're somewhat prepared when we come.

As this part is usually rather quiet, I like to play some casual music during the meeting. Recently I've started playing "top50" Spotify playlists, every time from a different country. It's a small, but fun thing, and it gives the meeting a bit more casual vibe.

I always ensure everyone is done writing before we move to the next step. If someone needs more time, we wait 2-3min more.

Discussing cards (15min)

The next step is to discuss all the items. This part of the conversation focuses on understanding what the author meant. We do not discuss the solutions and we don't argue that the problem doesn't exist. This part is about understanding the problem or the celebration. While discussing cards, we often notice that some thoughts are repeated, and we merge those cards together. After 15min we end up with a list of unique celebrations in the "went well" colum and a list of unique problems in the "to improve" column.

Voting

The next step is to understand which items on the lists are the most important, so that we can focus on them. Every participants gets 5 votes and we take 1-2 minutes to choose the problems we want to solve the most. The outcome of this step is that both columns have items sorted by number of votes.

Finding solutions and creating action items (20min)

Next we go through the most voted items. In the "went well" column, we acknowledge that these items made the most positive impact on the team in the last month, and we check whether any action item is needed to continue doing the good stuff.

Most of the discussion focuses on the "to improve" column. For each item we try to come up with solutions that can help solve the problem entirely or at least minimize its impact. Sometimes there's no real solution, sometimes the solution is so far away from our scope of impact that it's really impossible, but we acknowledge that. It's good to say "I know this bothers us, and we have to live with it", because at least we feel that we understand each other, and that makes it easy to stay motivated. Most of the problems have at least solution, though.

The outcome of this step is a list of action items that we plan to take.

Choose the items to focus on

In the end of the meeting we have a few action items. Sometimes there are 2-3 of them, sometimes there are 10. I ask the team what are the items we want to focus on in the next month. Usually we assign 1 item to each person, so that everyone has something to work on, but we are not overwhelmed.

The remaining items stay unassigned. I keep them as future ideas, if we ever run out of things to improve.

When we're done, I thank everyone for participating. The meeting is over, but the work just begins.

After the meeting

Immediately after the meeting I organize the notes, especially action items so that everyone in the team can easily access them and so that I can keep track of what we discussed and agreed on.

Every once a while I'll look at that list again and ask people about their progress – are we introducing the changes we agreed on? If not, why? Is anything blocking us? What can we do to get it done?

I always ensure that at least a few items on the list get done. And this is the real secret of keeping the retrospective going – I make sure that we get things done. When we come to the next retro a month later and we look at the past action items, we see a real progress. That encourages everyone to participate actively, and keeps the team motivated.

Good retrospective is simple

No fancy tools or formats will save your retrospective if you don't ensure that the team keeps improving. Sure, it's good to have a tool that allows anonymous voting, it's good to have a tool that will email a retro summary to everyone, but it's just a detail, a nuance. What you really need for the retrospective to be successful is to listen, analyze, and act. This is the only way to keep the team engaged and motivated for months or years. If you stop working on the action items, if you stop improving, the retrospective will become yet another useless agile ritual that the team attends only because they have to. Don't let that happen!