I’ve had very good feedback on the approach I’ve taken to run my retrospectives, and I thought I’d share my approach here.
The approach I take is a mixture of experience from working with very good project managers and the format outlined by the Retromat, the activities of which I use and adapt frequently!
One of my retrospectives is structured like so:
- Review the actions list
- Check how everyone’s feeling
- Collect evidence
- Generate actions
- End on a high
I always start my retrospectives by going through the list of actions from the last retrospective and ask if we implemented it and achieved the goal. If we didn’t implement it, then we ask why (maybe the idea wasn’t so valuable after all) and if we should drop it. If we did implement it, then we check it worked as intended and if it was a process change, if we should make it sticky.
The remaining parts are always really cheesy, but they work well. To check how everyone’s feeling, I always start by asking a question like:
- if you were a car in the previous fortnight, what type of car would you be?
- pick an emoji which summarises how you feel about the last fortnight?
- what gear is this team currently in?
If there are huge differences between the answers (if one person feels like a Volvo with 100,000 miles on the clock and everyone else is a Ferrari, that person might be on the verge of burning out), then that’s the most concerning, moreso than if everyone’s negative (you can address the negativity in the later stages).
With this in mind, you can then move on to the evidence generation. There are a tonne of techniques to do this, from asking the tried-and-tested Start/Stop/Continue, Mad/Sad/Glad, etc, to themed questions like “what would make the team change up to the next gear” and “what would cause us to change to a lower gear”
I find it important to vary the question asked, as different (although similar) questions can get people to think about things from a different perspectives.
With this evidence you can then cluster into themes and come up with actions to address the issues raised (either positive things that worked to bake into your process, or something to try and review at the next retrospective). In the event of lots of clusters emerging you could use dot-voting to focus on the most important.
To close the retrospective, I always like to end on a high note. There are a bunch of ways to do this: what was your favourite moment/feature since the last retro, what did you learn in the past fortnight are common questions. There is a favourite I have, but you can’t overuse it and I can imagine it being demoralising if there’s an under-performer on the team, and that’s where everyone has to say thank you to one other person for something they did in the past fortnight (so everyone has said and received exactly one thank you).
It may be cheesy, but I always enjoy running the retros, and my team enjoy attending them!