Shift left for more meaningful retrospectives
Distributed teams should view retrospectives not as meetings but as processes with both async and sync components.
- Going by the ConveRel quadrants, retros fall in quadrant 4 and the input gathering and synthesis should happen async.
- You can choose to asynchronously vote and prioritise issues for discussion, but since this is a short exercise, you may not get much benefit doing so.
- Be sure to set up the retrospective environment in advance with all the synthesis in place, so you can run the actual meeting effectively.
- Use the Mural templates on this site to give yourself a headstart with setting up the retro environment.
Agile software development is all about continuous improvement. The iterative process allows the team to learn from experience through feedback and reflection. One of the agile rituals that promotes reflective thinking is the retrospective. Here’s how I define this ritual.
A retrospective is an event that allows teams to reflect on how they’re working together, in a blame-free, safe environment. The goal of this event is to learn from their collective experience, to recognise the team’s strengths and to explore ways to improve the team’s effectiveness in the future.
Retrospectives, or retros as we commonly call them, are usually meetings. In a distributed team, that by itself can be problematic. That’s not the only problem, though. Many teams don’t conduct retrospectives for months. This leads to a backlog of thoughts and ideas in people’s heads. When they take part in a retro, these ideas come in a deluge. We spend a major part of the meeting just collecting and synthesising these inputs. You can use hard time boxes to keep the meeting moving, but after a certain point, that may be counterproductive. When retros don’t yield meaningful outcomes, people lose faith in them and they become tick-box activities.
The other problem with retrospectives is irregularity. Without a ritualistic forum to share their ideas, team members can feel uncertain about whether ideas are really welcome. That lowers the sense of safety and openness for people — a prerequisite for effective retros. If not for each sprint, aim for a retrospective each month.
Most agile coaches will agree with me when I say that a practice of effective retros is crucial to the effectiveness of such teams. There’s plenty at stake to make the ritual effective. In today’s post, I want to share with you how you can run effective retros for your distributed team, with a solid sprinkling of asynchronous methods. For simplicity’s sake, I’ll assume that you’re running the retrospective, but you can always bring in a neutral facilitator.
What you do outside the meeting makes the meeting effective
Let me take you back to the ConveRel quadrants. A retro is a typical quadrant 4 activity. If you pare it down, you can view the retro as four smaller activities.
Collect inputs. Depending on the format of the retrospective you want to run, your team will have to think about the time gone by and answer a few questions. The most common retrospective questions are, “What went well?”, “What didn’t go so well?”, and “What puzzles you?”. Other formats will have different questions.
Synthesise inputs. This is where a facilitator groups similar inputs together using affinity clustering. This allows you to see clear themes of what’s on people’s mind. Back in the day, we’d facilitate retros using sticky notes on a whiteboard or flipchart and that approach lent itself well to clustering. In a remote setup, you can use collaborative whiteboards like Mural or Miro to achieve similar, or even better results.
Vote to prioritise. You can’t try to address all themes in a single sitting. So you need to prioritise what’s important to the group. Typically, we do this by getting people to vote on the themes. That way you can bubble up the top three or top five themes - depending on how many you have the appetite for.
Commit to actions. This is where the rubber hits the road. The team discusses each of the prioritised themes and commits to actions for each of them. It’s good practice for specific people to sign up to complete each action. In fact, I recommend you track these actions on your team’s task board.
A retrospective timeline
That list should tell you a few things.
#1 and #2 can easily happen asynchronously. Get those out of the way. You’ll give people the time to be thoughtful.
#3 is possible to do asynchronously, but you need to phrase the themes in a way that people understand them well.
#4 is also possible to do asynchronously, but be mindful of a few challenges.
If the team doesn’t have a high level of safety, you won’t get honest inputs in an asynchronous environment. Especially with newer teams, you’ll find it easier to get inputs in synchronous setup.
Agreeing on actions can benefit from a fast-paced exchange of thoughts. Speed is one feature asynchronous communication doesn’t have. So even in a safe team environment, doing this asynchronously may feel like pulling teeth.
Of course, as you get more adept at working asynchronously, you may not need a meeting at all. Don’t rush that transition, though. It’s ok to shift left in baby steps.
Collect inputs in safety
While you can facilitate the retrospective on a collaborative whiteboard, it’s tricky to collect inputs on the whiteboard itself. Not all whiteboards preserve anonymity, and if you’re unsure of the team’s safety level, this is not ideal. So I suggest using a survey form instead to collect these inputs. Here’s an example of such a survey form.
Be sure to agree on a due-by-date for survey responses, otherwise you or your facilitator may have to wait indefinitely. If your team isn’t used to asynchronous work and the accountability that comes with it, you may have to remind people individually as well. Once you have all the responses, you can convert them into sticky notes on your whiteboard and cluster them for everyone’s benefit. Next, you need to vote on these themes.
Voting synchronously vs. asynchronously
As I mentioned earlier, it’s possible to conduct voting asynchronously. If you do this, take extra care to name each theme in a manner that makes it easy to understand, even when stripped of context. You could choose to do this on the collaborative whiteboard as well, but then you’ll need to set it up with a voting session running indefinitely and anonymously and that can be a bit fiddly, if you know what I mean. A cleaner approach, if you want to go asynchronous, is to send a survey form and ask people to respond to it by a certain time.
However, let me tell you what I prefer. By this time, you’ve completed most of the conveyance work. Voting just takes a few minutes in a real time environment. If you’re going to meet anyway, then it just makes sense to vote in that same meeting. You don’t lose any context that way and people have the chance to ask quick clarifying questions if something’s ambiguous. Which brings us to the retrospective board itself.
Setting up the retrospective environment
Screenshot of the starfish retro kit
If you’re new to facilitating retros, I have just the thing for you. There are a few Mural retro-kits on this page. If you don’t use Mural, that’s ok - you can find equivalent kits for Miro or make your own. Tools like Parabol have purpose-built interfaces for retrospective meetings, so look at them, too.
I intend for my templates to be references; especially for new facilitators. In the image above, you see an example of one of these murals - the starfish retro kit. It has a bunch of familiar sections that I repeat across most retrospectives I run.
| Safety check | This section calls out the retrospective prime directive, which goes like this.“Regardless of what we discover, we truly believe that everyone did the best they could, given what they knew at the time, their skills and abilities and the situation at hand.” By stating the prime directive up-front, you let everyone know that this is a blame free environment. You can then ask people to anonymously indicate their level of safety - five being the highest, and one, the lowest. I prefer doing the safety check synchronously, though you can do this asynchronously as well. You can choose to do this after collecting inputs or even earlier - your judgement call. Your safety check may sometimes tell you that people are not feeling safe. If you encounter such a situation, I’ve outlined a synchronous facilitation strategy here. |
|---|---|
| Brainstorm | This is where you bring in all the inputs and synthesise themes for everyone’s benefit. When you conduct synchronous voting, people can cast their votes in this section as well. I recommend that you give people 5-10 minutes after the safety check, to review each theme and to ask clarifying questions. Once they’re clear about what each theme stands for, you can run an anonymous or open voting session depending on the safety level of the group. |
| Actions | Once everyone’s prioritised the themes they wish to discuss, you can scribe all actions in this area along with the owners and the due dates. |
| Kudos | Retros can get overly focussed on improvement and not enough on appreciation. Adding a kudos section allows the team to say thanks to anyone who enriched their experience at work. |
If you use any of the templates I’ve created, you’ll see facilitation instructions embedded. Follow them step by step and you should be on your way. When you’re done with the meeting, be sure to find a central place to track the actions from the retro. Your team task board is a sensible default.
The retrospective “process” adapted for asynchronous agile
In summary, when you’re in a remote setup, think of your retro not as a meeting, but as a process. That process has two parts - asynchronous and synchronous. How much you do asynchronously is totally up to you and how adept you feel with working this way. That said, it’s best to give people async time to provide inputs and for you to synthesise those inputs meaningfully. So I recommend a week for this part of the process. The rest of the process can easily happen within a 60 minute window. If you haven’t had retros for a while, make it longer. By the way, my colleague and author Paulo Caroli runs a brilliant companion site for his book - fun retrospectives. You can also use the companion app to make running retros easy for yourself!