How to run effective retrospectives for agile teams

I struggle with the concept of chores. Every time I sweep my floor, I can’t help but think that I’ll just need to sweep it again next week, and the week after that. I see a long, unending chain of sweepings in my future, each one no different from the last, and each one aimed towards the exact same objective: a clean floor.

Maybe I should get a Roomba.

Even if I did, though, no amount of automation currently available to me is going to result in a clean apartment without any effort on my part. Despite my best efforts to be tidy, the mere act of existing in this space messes it up over time.

Our work is like that, too. A high-performing programming team isn’t something that appears out of thin air, unmodified. A congested server doesn’t maintain itself the day it’s plugged in. A critical software system doesn’t glide into existence with never a need for refactoring.

For most of us, these things require human attention, to counteract the natural entropy of existence. Team cohesion requires the same attention and maintenance as anything else, and that upkeep is a bit more complicated than sweeping a floor. If your goal as a leader is a team that gels, it’s important to be proactive in this area.

One approach to team maintenance is the retrospective meeting, also called a “retro”.

In this post, I’ll give you a basic overview of what a retrospective is, and provide a starter guide for implementing them on your team.

What is a retrospective?

The concept of a retrospective meeting provides a process implementation of the 12th Principle of the Agile Manifesto, or what scaled agile methods sometimes call the inspect and adapt cycle:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Retrospectives frequently show up in agile processes such as [Scrum][scrum], but your team can hold retrospectives regardless of your process. A retrospective, at its core, is a meeting in which a team talks about its own performance. Many software teams build continuous integration processes to improve the quality of their code; think of retrospectives as a similar concept for the human elements of a team.

A well-executed retrospective cadence offers several benefits:

• open communication: A retrospective should be a safe, high-trust environment. This allows the team to be honest with their feedback and get comfortable surfacing potential problem points. Sometimes this means having uncomfortable conversations, but that’s preferable to letting frustration fester
• ownership: The team uses a retrospective to generate ideas for improvement. If they’re also allowed to implement those ideas, they’ll pursue those ideas with a higher degree of investment
• autonomy: The retrospective process encourages team members to contribute solutions that are within their area of influence, instead of waiting for someone else to address it

Caveats about restrospectives

Retrospectives work best on small, self-organizing teams. That’s not to say a big team can’t hold one (I’ve seen successful retrospectives with groups of 20 people), but it takes a little more effort to ensure everyone’s voice is heard.

Since the emphasis is on looking for solutions and improvement, it’s important that the team has the power to make the changes they need, as well as the leadership support needed to do so. If you’re going into this as a manager or leader, try to help your team understand the scope of your influence as well as theirs.

The next thing to remember is that it takes time for a group of people to get comfortable speaking frankly. If your team’s first retrospective is thirty minutes of blank staring, don’t panic. Facilitating a retrospective is difficult; it’s honestly a subject worthy of its own post. Try to encourage the team to speak up by asking leading questions and providing room for honesty.

Finally, retrospectives and their data should never be used to measure performance. I can’t stress this part enough.

The best way to destroy any hopes of trust or transparency in a retro is by bringing a team member’s comments back to bite them in their yearly review. For this reason, some coaches recommend an explicitly limited role for managers in a retro, if they attend at all. Be aware of the influence that a leadership presence may have on the team.

So, you want to hold a retrospective

If you’re still with me, then hopefully you’re sold on the concept of retrospectives and are ready to make a plan. The rest of this post serves as a quick-start guide for a team’s first couple of retrospectives, compiled from several excellent resources. It’s designed for teams that don’t have ready access to an agile coach—if you do, use them!

Agile Retrospectives provides a rough outline for the typical retrospective:

1. Set the stage
2. Gather data
3. Generate insights
4. Decide what to do
5. Close

A retrospective is usually 1 hour or more, depending on the period of time the team will be reflecting on. If you’re running the Shape Up method and holding a retrospective once per 6-week cycle, 2 hours may be more appropriate. Retrospectives that cover an entire quarter may require a half or full day.

For the first couple of retrospectives, I’d recommend focusing on a smaller span of time, such as a two week sprint for one hour.

This will help keep the conversation focused while the team is warming up to the idea of a retrospective, and help prevent fatigue. A good retrospective can drain people’s energy (being open and honest requires a lot of work), so don’t be afraid to schedule breaks in advance.

Note for remote teams: If you’re holding a retrospective over a video call, Trello and FunRetro are a couple of software alternatives for a whiteboard.

Setting the stage

The first few minutes of a meeting can be used to communicate the goals of the meeting, provide an agenda, and perform a warm-up activity.

Introduction

The first page of the Spotify Retro Kit (which is a useful quick-start on its own) is great for kicking off the tone and purpose of a retrospective. The “How to” page contains a Retrospective Prime Directive, which can be reviewed with the team at the start of the meeting:

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.

This directive reminds the team to stay positive and drive the discussion from a place of improvement rather than judgment. Next, take a look at the “Spheres of Influence” beneath the Prime Directive, which encourages the team to focus their discussion on the things that they have control over and the things they can influence. If the entire retro is taken up by talking about things the team can’t change, it’s going to be tricky to pull out any action items.

Agenda

The agenda is a quick overview of what the team will do, how long it will take, and when the breaks (if any) will be during the meeting. That way everyone knows what to expect.

Warm-up activity

Before the brainstorming begins, it’s a good idea to have a very quick game or activity to get everyone warmed up. The warm-up activity should be simple and quick. It’s not a launchpad for any serious discussion; it gives everyone a chance to learn how their teammates are feeling about the last cycle. The primary goal of the warm-up is to get every member of the team to communicate something.

“When people don’t speak early, they may not contribute at all—and may not buy into the team’s insights and decisions.” - Agile Retrospectives

Here are a couple of example warm-up activities:

• Everyone takes turns saying one or two words about how they felt during the last cycle (or whatever period of time is covered by the retro). They don’t need to provide significant detail or explanation.
• Everyone gets one minute to post an emoji (or combination of emoji) somewhere everyone can see it, such as Slack. Then, everyone takes turns briefly explaining their choice.

Gather data

A great starter format for retrospectives is Start, Stop, Continue, which can be used to perform most of the brainstorming.

First, create three sections on your whiteboard or retrospective tool:

• Start: What things do you think the team should start doing?
• Stop: What things are the team currently doing that you think we should stop?
• Continue: What things are the team currently doing that should continue (what’s going well)?

This format keeps the emphasis on specific actions rather than outcomes. Rather than saying “stand-ups were terrible”, a team member might add “long one-on-one technical discussions during stand-up” to the Stop section.

Generate insights

Once all the items have been added, the team votes on which items they consider highest priority. This can be done with stickers or application voting tools. The team then goes through each section from highest to lowest priority, and discusses each item for a few minutes. Create a fourth section, called Action Items. As the team discusses the Start and Stop items, they should try to pull actionable tasks out of the items and move them to the new section.

If, for example, one of the items is “Start pairing more regularly”, an action item could be “set up a team pairing schedule”. This helps direct the conversation towards how that particular item can be improved during the next cycle, and creates a task that someone can be accountable for.

Note: It’s very easy to forget about the “Continue” section, but please don’t! Encourage your team to get comfortable bubbling up and celebrating the things that went well, not just the things that didn’t.

Decide what to do

Once the team has a few action items, the last part of brainstorming is choosing which action items to implement before the next retrospective. This should be a small, attainable number, to ensure that the team has the bandwidth to complete them. Assign those items to members of the team for accountability, and post them somewhere visible. During the next retrospective, the team can review the status of those items.

Wind down your retrospective

Set aside the last few minutes of a retrospective for winding down. Thank everyone for participating, and review the brainstorming outcomes based on the current state of the board.

If time permits, maybe perform one final activity to gather feedback on the retrospective itself. One way to accomplish this is to ask everyone to give a thumbs up / down / sideways to indicate how they’re feeling about the retro, then ask the individuals who give thumbs down or thumbs sideways to suggest changes that would increase their vote. Fist of Five is another good closing option.

Summary

Whew, this was a long post, so thanks for reading this far. Hopefully it provided a useful starting point for you, whether you’re new to retrospectives or simply looking for a friendly way to introduce them to your team.

But I’ll be the first to admit that nothing here constitutes the “best” method for retrospectives, because there isn’t a best way. Remember that this is all based on the concept of “inspect and adapt”—if something isn’t working for your team, feel free to experiment. The keys are open communication, trust, and flexibility.

Good luck, and happy retrospection!