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.
Running the 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.
10 minutes — Warm-up + recap previous commitments
5 minutes — Gather data
40 minutes — Generate insights
5 minutes — Decide what to change
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:
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!