Are people not contributing in your sprint retrospectives?
Are the retros too long or boring?
Does what you discuss ultimately get ignored?
This almost reads like one of those cheesy television adverts, that then follows up by saying, ‘then you need <our product>!’.
In the case of retrospectives, the thing you require isn’t a product or service, but variety. This could be a new perspective, change of pace, or someone different running the session. Mixing things up keeps retros engaging and fun.
The key is to experiment. Sometimes you might want to focus on the big stuff. At other times, get down to the nitty-gritty details to see how you can improve them. As the saying goes, take care of the pennies, and the pounds take care of themselves…
Why retros matter
A well-run retrospective will surface important things that your team can improve, to make subsequent sprints more productive and enjoyable. If retros are neglected, they become boring, and tend to tease out the same things every time. And let’s face it, we’ve all got better things to do than sit whinging for an hour on a regular basis…
So how can things be done better?
Let’s look at four ways to mix up your retros for the better.
1. Get different people to run your retros
Rotate your facilitator on a regular basis. Switching things around builds a sense of ownership among your team, and also helps colleagues develop their facilitation skills. And of course, retros don’t necessarily have to be run by someone from within the team.
There are different ways you can operate this in practice, including:
- Rotas: Everyone gets a go, in turn
- Randomisers: Use a random picker to select who should run the session. Do this at the end of the previous retro, to give the next facilitator time to plan the session
- Ask for volunteers: Not everyone will (yet) feel comfortable running a retrospective, or have the experience needed. So rather than making it mandatory, you may prefer for it to be optional
- Pair facilitators up: One way of addressing any confidence or experience gaps in your team, is to get people to run retrospectives in pairs. This could be with other colleagues, or with the scrum master. We’ve found the latter is a useful way of the team leader learning what their team wants from its retros
- Use an outside facilitator: Get someone who isn’t in the team to come in and run their favourite retro. If you’re working in an organisation with multiple agile teams, you can do this on a rota basis, so that every team benefits from others’ experiences
2. Ban the same retro
Have a rule that the same type of retro can only be used once every quarter. While this may sound like a tall order in terms of the number of different approaches you’ll require, for most teams working with two-week sprints, this only needs six different retrospectives.
I’ve done this for the last six months, and it’s really forced us to be creative and come up with new types of retrospective. The great thing about it is that what colleagues come up with is perfectly tailored to that team, in that context.
If you’re looking for ideas, the Agile Retrospective Resource Wiki has a great page on Retrospective Plans.
3. Mix up the length of your retro
Altering the length of your retrospective can force people to do things differently. So every now and again, set yourself or a colleague the task of running a productive retrospective in under half an hour.
This will help the facilitator develop the ability to tease out important lessons learnt when time is short.
If this approach is successful, it can be tempting to slash the length of all your retros. But that shouldn’t be the aim. In fact, there will be times when the activity you’re planning merits an extended session. As we said at the start, the key is variety.
4. Alter the focus
A lot of the time, your retrospectives will be looking back at a sprint or a deliverable. These don’t always have to be your focus, though.
Consider, for example, doing a quarterly team health-check retro. The Spotify Squad Health Check model is a good technique.
Equally, you could focus a retro entirely on one big systemic issue and explore what to do about it. Get ideas from your team, and then see how you could put them into practice. And if solving the issue is beyond your immediate control, the inputs from the team retro can form useful evidence when you raise the issue with others.
And as well as looking at big, strategic challenges, there could also be tactical issues worth devoting a retrospective to solving. Are there some tricky technical decisions coming up that need deeper consideration? Is there some technical debt that’s hampering the team in some way?
Variety is the spice of life
We hope this has given you some ideas for how you can keep your retrospectives spicy and interesting. We’d love to hear your thoughts as well – and if you’ve got any questions about what you could do in your specific scenario, feel free to get in touch too.
