Well Met: How Truss Does Retros
A good retrospective is the most important regular meeting a team should have. When done well, the retrospective provides a clear way for a team to make incremental improvements over time.
There are a lot of different types of retrospectives, so it can be hard to know where to start. In addition, many types of retrospectives can devolve into feel-good exercises with no resulting actions. Talking about feelings is important; a highly functioning team will talk about heavy topics in a retro when necessary, and they will also end up with actions that lead to the team being improved.
At Truss, we really like a retro process that we modified from one that the Gov.UK folks came up with in 2013. It's fairly rigid in terms of time management and focuses on collecting and assigning actions to the team.
When you're starting to introduce retrospectives into your organization, do them frequently: every two weeks until the retrospective starts to feel empty. This can take a while if your team has a lot of ideas for improvement. Once the retrospectives start to calm down, increase the interval between them by a week and see how that feels. Once everything is going smoothly, you'll end up with a retro every four to eight weeks, depending on how much is changing around your team.
The entire exercise should take 90 minutes. The timeline here includes an extra 10 minutes of slack so that you always end on time.
Before you begin
Identify the facilitator and a note taker. The facilitator runs the meeting, makes sure it stays on track, and makes sure people are heard. The note taker makes sure possible ideas and actions are collected as the meeting progresses. (We usually use a Google Doc for this.) When we run meetings in person, only the note taker has a computer; the facilitator usually uses a timer on their phone for each section.
Collect a bunch of markers and post-it notes. You'll need them. Book a room where your team will be undisturbed for 90 minutes.
00:00–00:05 (5 min): Set the scene
The facilitator should make sure everybody is in the room, settled, laptops down. Remind everyone what's happened since the last retro (the highlight reel) and, if necessary, how the process works. If this is your first retro, this is a great time to walk through the entire process. It's ok if it takes more than five minutes; you won't have any actions to review if it's your first one.
00:06–00:10 (5 min): Review actions from last retro
Quickly go through actions from the last retro and confirm that they have been completed. If an action hasn't been completed, do not automatically carry it forward; it didn't get done for a reason. If it still matters, someone will almost certainly bring it up again.
00:11–00:20 (10 min): Write down good stuff on post-its
Each person on the team should write down good things, with one item per post-it. Good things are: things that went particularly well, things that the team wants to continue doing that helped, and things that the team wants to do more of.
Once folks are done writing their post-its, they should put them up on a wall in the room. It's ok if folks finish early (although don't be too eager to cut a section short—you want people to have time to reflect).
00:21–00:25 (5 min): Read the post-its out loud and group them
For each post-it, read it out loud and group it into whatever themes you find. It's pretty common for a given team to have regular themes (Process, Tech, Team, Other is a grouping I've seen a few times, but there are lots of ways to do it). Reading the post-its out loud helps folks who learn better from listening than reading; it also allows people to clarify a thought if it was confusing.
If you've done the process a few times, this can be a good time to have people come up and put a dot on post-its they think are important to discuss. That makes it easier to spend more time on the discussion phase. However, since it does add complexity, it's ok to skip this step, particularly in your first few retros.
00:26–00:35 (10 min): Discuss the good
Have a group discussion about what's on the board. If your team is new, try going theme by theme and asking questions like:
What should we keep doing?
Why did these go well, and what can we learn?
Are there actions that someone here can take?
Ideally, at the end of this time you've talked about a couple of the post-its and have a few possible actions in your notes. You are not trying to talk about everything on the board at every retro.
At the end of the time, the note taker should take photos of the post-its. These become valuable over time; being able to review retros for a team over a quarter can be a great way to see long-term trends or persistent items that never quite make it into the discussion.
00:36–00:50 (15 min): Write down bad stuff on post-its
Yes, you spend more time on the bad than the good. This is because most of your improvements are going to come from discussing what didn't go well and how to fix them for next time. It also keeps teams from being too focused on self-congratulations. Bad things are anything the team wants to stop happening or things that went poorly.
Once folks are done writing their post-its, they should put them up on a wall in the room. It's ok if folks finish early, but be very cautious about cutting this section short. It can take a few minutes of people just sitting before something bad comes to mind. Many software engineers are optimists, after all.
00:51–00:55 (5 min): Read the post-its out loud and group them
Just like what you did in the good part. Your themes for the bad part don't have to be the same as the themes for the good part.
00:56–01:10 (15 min): Discuss the bad
Have a group discussion about what's on the board. If your team is new, try going theme by theme and asking questions like:
Can we work out why these went badly?
Can we work out what we need to do to improve matters or prevent specific things from happening?
Are there actions that someone here could take?
It can be uncomfortable to discuss the bad stuff. The facilitator should be aware of the mood of the room and shouldn't tolerate rudeness. Radical candor is the goal; a high-functioning team can tell each other when they've failed without things getting ugly. It can take a while to get there; don't worry if your first retro only has complaints about the kitchen.
Ideally, at the end of this time you've talked about a couple of the post-its and have a few possible actions in your notes. You are not trying to talk about everything bad on the board at every retro.
At the end of the time, the note taker should take photos of the post-its.
00:11–01:20 (10 min): Discuss potential actions
The note taker should go through each possible action that was collected in the retro. For each action, the team should make sure everyone understands it, decide if they want to do it, and, if so, assign someone present to complete it, ideally by the next retrospective.
It's not unreasonable to have five to ten actions from this meeting, ranging in severity from "Please ask Facilities to raise the temperature in here because we're freezing" to "Work with Security to make sure our deployment process doesn't require unprotected secrets on our laptops". Track those actions the same way you'd track project work. In our case, that often means they get added to Pivotal Tracker.
Afterwards
The note taker should put the notes and photos in a well-known place where the team can get to them later. We use a shared Google Drive folder for this.
Variations
The retro process isn't static; you can and should adapt it to your specific team’s needs. At Truss, we generally try one change at a time as an experiment. One variant that we do use, though, is when the team is distributed and can't be in the same room.
In that case, everybody joins the same video conference (we use zoom.us), and we run the normal retro process. Instead of post-its and a whiteboard, we use a shared Google doc that folks draft into (usually by writing up thoughts, one per line, and then pasting into the doc at the end).
Another modification to the basic process that's worked well for us was to establish two slack channels (#retro_good and #retro_subpar) to let folks raise issues in between retrospectives as described in Nick Twyman's post about how we use Slack.
We've found that we get the best results when the facilitator actively moderates the discussion sections of the retrospective to ensure that everyone on the team has an opportunity to speak. This does require the facilitator to be comfortable moderating a discussion; we're lucky in that we have a couple of folks who have formal training in this skill, and they both facilitate and train others who want to give it a try.