Asynchronous agile

View Original

Shift left for more meaningful retrospectives

See this content in the original post

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.

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

The ConveRel quadrants

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

See this content in the original post

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!