Why we retrospect

This is part of a series where we share how we work at LloydsDirect.

I have the sudden feeling that I’ve joined a cult. We are sitting in a circle, me much higher, perched on a chair, while everyone else is slouched back on a sofa or bean bags. Everyone is quietly writing on post-its with Sharpies. I’m armed with the same, but I’m not writing anything, as this is my first week on the job and I’ve never been to a retro before.

Next, everyone takes turns reading out one of their post-its, sharing something that had gone well or, more frequently, something that could have gone better. Once done with a post-it, they chuck it into a pile on the coffee table in the middle of the circle. This part is much more interesting, and I take notes of the pain points that people mention, though I’m still not quite sure where this is going.

Once everyone has exhausted their post-its, someone collects the pile of post-its and thanks us for our time. She later emails us all a list of 28 things that could’ve gone better (omitting the duplicate entries).

Little do I know that over the next six years I will participate in over 200 retros like this one. Well, not quite like this one. They do get better.

The purpose of a retrospective is for a team to improve how they work together. That is all. This is why we do it. The name suggests a way of identifying improvements: by looking back at what has already happened. Beyond this, all the ceremonies and rules on how to run a retrospective are just aids, a way to improve how we work together as a team.

Retros are an opportunity to course correct. The less often you retrospect, the more you might have blown off course. As with anything, more practice leads to better retros. Regularity breeds familiarity, allowing people to spot things to bring up things in retros.

Like many aspects of business culture, retros are prone to cargo-culting: teams and organisations adopt them because they think they should, and they repeat them without really thinking about why they take the shape they do. Maybe retros were introduced by someone who understood them but who since moved on, and the tradition lived on, the rituals perpetuated but their purpose long forgotten.

There were several problems with those first retros that I experienced. They ran long — so very long — usually lasting 90–120 minutes. And despite this, we never discussed how we could avoid the things that hadn’t gone well. Neither did we prioritise the issues raised; there’s no way that a team can change 28 things in one go. These retros were good for catharsis but not much else.

I participated in many poor retros before I read the book on retros (pdf) and realised just where they came from and what value they could unlock. Coming in at a mere 150 pages, a waif of a software development book, Agile Retrospectives is well worth a read.

I’ve used the names of the stages suggested in Agile Retrospectives in my retro recipe below, though the details of what to do in each stage are not from the book. The book has many great different techniques you can use for each different stage of a retro.

The recipe for a retro

In preparation

• Choose a warm-up exercise (e.g. “three words that describe your week” or “score of 1–10 on how you feel at the moment”); write this down as a heading on your physical or digital whiteboard
• Decide on two prompt questions to ask; my go-tos are “what went well?” and “what could have gone better?”; write these down as headings on your whiteboard
• On the side of the whiteboard, list the names of the participants in a random order, this is your running order

Running the retro

Set the stage

• Warm-up — this exercise is intentionally abstract and helps everyone get a sense of how each team member is feeling; it’s intended to help create an atmosphere where everyone feels safe to talk about potentially difficult topics
• Recap previous retro commitments — Have we kept our commitments? Have they helped? Should we experiment with them further? If so, they can be re-introduced in the “Gather Data” section

Gather data

• Let everyone know how much time they have and set a timer
• Ask everyone to think up as many answers as they can for each of the prompt questions
• One answer per post-it
• When writing post-its, have everyone write all their answers at once (there’s no need to first consider what went well and then what could’ve been better)
• Once the time is up, the first person in the running order chooses one of their post-its, reads it out and places it on the board
• Once they’re done, they hand over to the next person in the running order (the last person hands it to the first) by saying their name
• Once a person has placed their last post-it, they scratch out their name in the running order
• Rearrange the post-its as you go, clustering the ones with the same topic together
• If anyone has a post-it on the same topic, have them place it immediately (not waiting for their turn)

Generate insights

• We don’t have time to analyse everything (nor the capacity to change too many variables at once), so we contain this by voting on what topics would be most valuable for the team to dig into together
• It can be something that has gone well (i.e. you want to think about how this can be repeated or amplified) or something that could have gone better (i.e. how can you avoid this happening again)
• Vote using dot-voting, with 2–3 votes per person
• Votes can be for a specific post-it or for a cluster
• Once the voting is complete, start from the topic with the most votes and ask how we might adapt how we work in order to improve things
• At times, it can be helpful to do some clarifying of why the thing is beneficial/harmful — this breakdown can help suggest the root causes and potential adaptations (What things might have led to this? Why exactly is it harmful?)

Decide what to change

• Hopefully, you will have come up with some ideas to improve how your team works
• As a team, choose to experiment with 1–3 changes
• After the retro, these changes are shared in writing with the team (and revisited in the next retro)

The changes should be about how a team works, not what they work on. As such, any more than three changes are too hard to remember to incorporate. Your team still needs to cook the food, not just practise their chopping technique.

Example timings for a team of 5–10

10 minutes — Warm-up + recap previous commitments

5 minutes — Gather data

40 minutes — Generate insights

5 minutes — Decide what to change

Thoughts behind my recommendations

Why hand over to the next person? To make it clear that you’re done speaking, which helps avoid long silences or people talking over each other.

Why one thought per post-it? To allow clustering of similar ideas in order to spot common pain points.

Why write post-its (whether physical or digital)? To overcome an absence of data*. And to allow space for everyone to reflect at their own pace and to share equally. A free-for-all is quickly overrun by the more talkative members of the team.

* A eureka moment for me when reading Agile Retrospectives was that writing post-its in the “Gather data” stage is really a stand–in for other sources of data. If your team has other data available, you can and should incorporate this, too. The book has many helpful suggestions on how to help teams remember and structure their observations. For example, I’ve occasionally created a timeline of the events that happened in the past cycle to help jog everyone’s memories.

Why share only one post-it at a time? Taking turns keeps things snappy and distributes the attention more equitably. People only have so much energy to focus and it’d be unfair to have those going first to use it all.

How often should a team retrospect? This will depend on your team’s working patterns, but my experience is that fortnightly works best. Any less frequently loses a sense of regularity and is hard to remember what’s happened.

How long should retros be? This will depend on how many people are participating. For 3–5 people I’ve been able to run retros in 30 minutes. Teams of 5–8 need an hour. Much longer than an hour people tire and lose focus.

Should you vary up your retro formats/templates? Retros can definitely start to feel repetitive after a while. On the other hand, having a predictable format allows your team to anticipate how to contribute. When I run retros, they always use the same format; I find the novel questions (“what things are the wind in our sails?”) more distracting than helpful.

Who should run retros? Facilitating can be demanding, so alternating who runs it shares the burden. But when facilitating, it can be more difficult to participate, so I’m happy letting outsiders or more removed members facilitate when possible. Rotating every time also can mean that nobody gets particularly good at facilitating.

Who should join a retro? Everyone on the team or actively working together on something. Nobody else — no spectators!

Why not focus only on things that haven’t gone well? Two reasons:

1. We should celebrate the things that did go well!
2. By identifying things that have gone well, we can explore how we can do more of this

Are retros the same as postmortems? No. Postmortems or “end of project retros” are investigations into a singular project or incident. While they can be similar in format or technique, these aim to generate knowledge or procedures to prevent adverse outcomes for a broader group than a single team. The target audience is different. Team retros are solely for that particular team to inspect and adapt how they work together. What works for one group of people will be different to another team or the organisation at large.

Rules? We don’t need no stinking rules! No, you don’t! What I’ve shared are just things that we’ve discovered that work for us. You should adapt them based on your own experiences (though it pays to give it a few goes to see what works before changing it up).

In my experience, a formed team will start seeing diminishing returns from retros. This isn’t a bad thing — it means that the basic kinks have been ironed out! When this happens, it’s time to switch things up: change who runs your retros; adopt a new retro format; try examining what holds the team back from a new angle.

But before you do that, be sure to reflect on all the progress you’ve made. It can be easy to forget just how far your team has come. Reviewing past problems and seeing how they’re no longer an issue can be an eye-opening and energising experience.

Having had those hard conversations and pulled off that kind of change, you should have a well-oiled, happy and effective team. Good for morale and good for business!