Running an asynchronous retrospective

Reading Time: 4 minutes

The good, the bad, and the ugly

I seem to have been running a lot of retrospectives lately. And yes, I just used an Oxford comma. Get over it.

A simple, childlike image of a sailing boat on a choppy sea. The boat is held by an anchor hooked on rocks beneath the waves. There are wind puffs behind it and rocks in front of it. To the right of the images an island with a palm tree, with the sun overhead.
In the sailboat retrospective format, the boat represents the project or work we are doing; the wind is what is pushing us forward, the anchor what is holding us back. The rocks are dangers/risks we face, and the island is the goal or destination. I created this template in Miro.

In case you don’t know what that means, a retrospective (or a ‘retro’ for short) is a meeting-come-workshop where you look back on work you’ve done, as a team, and try to identify ways you could be better in future.

In agile methodologies, you can hold retros pretty regularly. With Scrum, you’d hold one at the end of every sprint – typically every 2 weeks – so you can get feedback quickly and adjust course immediately.

Think guiding a canoe through rapids; if you can’t change course quickly, you are going to hit a rock (a fairly common metaphor for retros uses a sailboat, as above) pretty soon, and pretty fatally.

That’s the kind of thing I’ve been involved with of late.

Retros get feedback from everyone on the team delivering the work to understand and consolidate everyone’s experience in a simple format. They can take many forms, but typically what you want to learn from them is:

  • What was good?
  • What was bad?
  • What are we (as a team) going to change?

Enter COVID-19

Before the Covid-19 pandemic, organising a retro was pretty straightforward. You’d get everyone in a room for a couple of hours – usually, they all worked in the same room all day every day anyway – hand out sharpies and stickies, and set them to it.

That picture’s a bit more complex now. Many people are working from home more-or-less permanently. Others have chosen to come back to (or enter for the first time) the office. Some folks can make the journey pretty easily. For others, it’s a lot more complicated; long-distance remote working is more common, childcare arrangements have changed, people’s habits and attitudes have changed.

The async retro

So towards the end of the last major piece of work I was involved with – migrating the SDI website to our new design system – we definitely wanted to run a retrospective. We have several other substantial websites we will be repeating this process with, so it’s important that we learn now and put what we learn into action next.

But it was proving incredibly tricky to get everyone together for the 90-120 minutes you need to do it properly.

After the date had been pushed back a couple of times because of other pressures and priorities, I decided to attempt an asynchronous retrospective. This was new for us, but what the hey. Probe, sense and respond.

The technology

We use Miro. Yes, I know it’s hideously inaccessible. But it’s becoming increasingly familiar to people outside the design teams.

I also knew from personal experience that no-one involved had accessibility issues except one person with low vision, and Miro’s zoom functionality worked for them.

We also use Teams. Yes, I know it’s hideously inaccessible, and generally hideous. But it’s what we have, and it’s familiar to folks now.

Other platforms are available, and you could use whatever works for you.

The process

I created a Miro board and added a default Miro template. It looked like this.

A virtual whiteboard with a series of instructions on the left. Then there are 3 columns, left-to-right, for 'What went wee', 'What could be improved', and 'Next steps'. There is specific guidance below each column, which is pre-populated with blank stickie notes.
The Miro template we used. Keeping it simple seems to keep it straightforward.

I modified the copy a little to be more reflective of what we were doing. I also added more sticky notes, in case they were needed, and checked in occasionally to see if yet more were required.

I also set up a short – 30 mins – Teams meeting, with a link to the Miro board, a week in advance. So it gave everyone a good opportunity to contribute their thoughts and experiences, whenever they could, then with the roundup at the end to go over what they had contributed. The shorter duration meant more people could join the call.

I spent an hour or two before the Teams call sorting the stickies into thematic groups and labelling them.

The outcome

… was actually way better than I expected.

We got really great, useful, actionable, and positive feedback. My fear was that the conversations that take place in retrospectives are normally the most useful things about them, and we would miss out on that richness, that nuance. The context.

But we packed a lot into those 30 mins. And we can, and will, follow up on any suggestions and experiences people had doing the work.

So I expect that asynchronous retros, and other agile “rituals” (I hate that word, agile is a mindset, not a religion – but it’s the parlance now I suppose) will become more common for us as time goes on.

People are busy, and we are not in the 2010s any more. We need to learn to adapt to that.

Website | + posts

I'm a service designer in Scottish Enterprise's unsurprisingly-named service design team. I've been a content designer, editor, UX designer and giant haystacks developer on the web for (gulp) over 25 years.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.