According to the State of Scrum survey from 2015, almost one 1 out of 5 teams don’t bother having a sprint retrospective. This is a real shame as they miss out on one of the best and most important parts of Scrum: trying to make every sprint a little bit better than the one before.
A cautionary tale
The two main arguments against retrospectives I tend to hear are:
- “We don’t have time for retrospectives. We’ve got real work to do!”
- “Retrospectives are pointless. Nothing changes anyway!”
I’ve been there too. On one team in particular, I discovered the hard way what could happen if you scrap retrospectives. We didn’t actively set out to do it but we were up against a tight deadline a couple of sprints away. On a whole, we thought our process was working ok, so we said “Let’s not do a retrospective this sprint and use the extra hour to complete more work in the sprint!”.
The next sprint, the deadline was obviously even closer so we skipped the retrospective again. And again. The deadline came and we missed it. That meant we really had to finish things in the next sprint. Definitely no time for a retrospective!
The result wasn’t good. Not only did our process not improve but it deteriorated. It should have been obvious that we had a problem with the pace not being sustainable but rather than stopping up for a second and thinking about how we could make things right, we just kept rushing ahead, thinking that we could talk about the process once we’ve delivered what we needed.
Only that we didn’t deliver. It went so far that we finally had to stop and go back to basics, reintroducing Scrum almost like a team would introduce it in the first place. By then, we had wasted a lot of time and effort.
The second argument against retrospectives is that they are pointless and nothing ever changes anyway. That can certainly be true but it doesn’t have to be that way. In this blog post, I will list some of my learnings from facilitating retrospectives over the last 10 years.
1. Don’t let it get boring
Repetition is the enemy of a good retrospective as a boring retrospective makes it hard for people to engage. As a facilitator, it is important to try to shake things up and introduce a bit of variation.
Also, if we always ask the same questions in the retrospective (e.g. “What went well? What didn’t go so well? What will we do differently next time?”), there is a risk we will keep getting the same answers. Mixing things up will help identifying different problems and create more creative solutions.
Some ways to vary retrospectives:
- Use different exercises. If you lack ideas, there are lots of sources of inspiration on the web and even whole books on the subject. I’ve found many good ideas on the website Retr-o-mat.
- If you tend to always let people write ideas on sticky notes (and most retrospective exercises tend to do), how about once in a while getting them to just shout them out instead? Or just have a good old chat?
- Take turns facilitating (see point 10)
2. Use a check-in exercise to get a feeling for what’s going on
A good way to start a retrospective is with a quick check-in exercise. This has two benefits:
- The participants get warmed up and into the mood for the retrospective.
- The facilitator can adjust the rest of the retrospective based on the mood of the team and the issues raised.
Basic examples of check-in exercises can be to let the participants rate the sprint by using a number between 1 and 5, an emoji or a word. The participants take turns revealing their answer and explain to the group their choice in just a sentence or two. Make sure to avoid any lengthy discussions at this point. A check-in should be quick. If something is worth talking about, someone will most likely bring it up in the main exercise.
3. Help people make themselves heard
Some people love talking while others are quite happy just listening. That doesn’t necessarily mean they are not engaging in the discussion. However, it is important that everyone gets plenty opportunities to make themselves heard.
Some tips that can help:
- If only a few people talk, try to bring the others into the discussion. For example, simply ask “What do the rest of you think?”
- Use exercises where participants get time to write down their points on sticky-notes. Rather than everyone putting their notes up on the wall in one go, let each participant put theirs up one by one and explain what they mean.
- When there is a natural pause in the discussion, avoid stepping in to fill the silence by asking a question. Instead, wait for people to speak.
- Sometimes, splitting the group into smaller groups can help (see the next point)
- Don’t put people on the spot. People are perfectly entitled to choose to remain silent. Don’t call them out in the retrospective. Instead, talk to them individually afterwards to understand why they were silent.
4. Make room for discussions by splitting into smaller groups
One technique I’m starting to use more and more, particularly when the team is quite big, is to split it into smaller groups for part of the retrospective. I find this is particularly useful when coming up with suggestions for actions to a specific problem:
- Agree the problem to discuss
- Split into small groups to discuss why the problem is happening.
- After a while, switch to identifying solutions. Still in the small groups.
- Let the small groups report back to the whole group, discuss a bit further and agree which solutions to proceed with.
5. Sometimes, you may want to identify a topic beforehand
Occasionally, it can be a good idea to identify a topic beforehand and use the retrospective to dig deep into that topic. This can for example be the case if some issue was brought up earlier but there wasn’t time enough time to find a good solution. Another example is when a team is new to Scrum and some bit of the framework isn’t working as intended but the team don’t know enough about how it is supposed to work or why.
Whenever I prepare a topic beforehand, I follow these three rules I have set myself:
- Don’t do it too often. The retrospective is the team’s meeting. They are the ones who should be identifying and solving problems. If I keep telling the team what I think the problem is, chances are I will miss the real problem.
- Use a check-in exercise (see point 2) to make sure there are no other big burning issues.
- Ask the team for permission. They may have more pressing things they want to discuss. Again, it’s their meeting!
6. Get to the root cause
I’ve written about this before so I’ll keep it short. Before identifying solutions, make sure you are tackling the root cause of the issue you are seeing, rather than just the symptom. Otherwise, the problem may go away in the short term, but resurface later. Either the same issue again or some different problem caused by the same root cause.
One simple method for root cause analysis is the 5 Whys. If you’ve set aside a whole retrospective for a single topic, a method like cause flow diagrams can also be a good help.
7. Identify clear actions
Making the next sprint better than the previous one requires us to identify actions. What will we do differently next sprint?
Good actions are:
- Clear and actionable. It is hard to complete an action like “Better acceptance criteria” as it’s far too vague. Where do we even start? “Schedule a weekly backlog grooming meeting to make sure stories have sufficient acceptance criteria ahead of the sprint planning meeting” is much clearer.
- Within the team’s remit. “Improve the stability of the build server” is not an action the team can complete if the build server is maintained by an Ops team. “Meet with the Ops team to explain why the build server needs to be more stable”
- Likely to solve the problem or at least contribute to solving it. This may seem obvious but it is easy for a discussion to go down a side track, coming up with unrelated actions.
However, I don’t think it’s fair to say that a retrospective without actions is pointless. For instance, if the sprint has been fraught with conflict, talking to each other to understand each other’s perspectives can be exactly what’s needed. Nevertheless, if not most retrospective identify concrete actions to improve the way of working, there is a problem.
8. Don’t list too many actions
You don’t have to capture actions for every single point raised in a retrospective. In fact, it’s much better if you don’t! As so often, less is more. If we only list the top few actions, chances are much bigger we complete them. It will also be easier to judge what changes are successful or not when there is not too much change going on at once.
The simplest method for narrowing down a list of actions is the ubiquitous dot voting:
- Merge any actions that are very similar, to avoid splitting the vote.
- Give the participants three sticky dots, or however many you prefer. If you are less equipped in the stationery department, a marker will work just as well!
- Let people place their dots on the three actions they vote for. If they feel strongly about a particular point, they can put more than one dot, and consequently vote for fewer actions.
- The actions with the most dots are your actions.
You can also use this method earlier on in the retrospective, to decide in which order to talk about the topics raised.
Finally, one surprisingly easy trap to fall into is to assume that just because someone is suggesting something, it is a good suggestion and we should do it. The originator of the idea obviously think their idea is worthwhile but don’t write it down as an action unless there’s been some discussion. If there seems to be different opinions, it is worth putting it to a vote.
9. Don’t bother with detailed notes
In terms of note taking, the important thing is to record the agreed actions. In my experience, anything above that doesn’t tend to be very useful.
At best, it is just busy-work, making the Scrum Master feel useful. It is quite rare for someone to refer to the old notes anyway. Worse, though, is that notes can also be in direct conflict with an important rule: whatever happens in the retrospective stays in the retrospective. For a retrospective to be worthwhile, people need to feel comfortable sharing their opinions. If there is meticulous note taking, making a record of everything that is said, this can limit what people are confident raising. Particularly if these notes are made available outside of the team, such as on a shared wiki.
10. Take turns facilitating (or get someone else to do it)
If the Scrum Master always facilitates the retrospectives, there can be a risk they feel like something that is done to the team rather than by the team. With a team used to having retrospectives, it can be a good idea to rotate the facilitation role in the team.
With someone else facilitating the retrospective, the Scrum Master can also take a somewhat more active part in the discussion. If no one in the team is up for facilitating, or if the team is too inexperienced to do so, getting a Scrum Master from another team to facilitate would also help with that.
Finally, different facilitators is a great way to create that important variation mentioned in point 1.
11. Don’t let the Scrum Master own all the actions
The default owner of the actions shouldn’t necessarily be the Scrum Master.
Most of the work going on in the sprint is not something that the Scrum framework describes but technical work. Unless the Scrum Master is also a hands-on developer, chances are the team members will be better equipped to carry out the actions.
12. Don’t forget about the actions
Just because something is agreed in a retrospective doesn’t mean that it will automatically happen. It is surprisingly easy to forget about the actions. Out of sight, out of mind. Suddenly, it’s the next retrospective and we have completed none of them!
That’s why it’s so important to make the actions visible somehow. A page on a wiki or an email is rarely enough as it requires people to actively go and look at it. Something more “in your face” is preferable. One way is to post the actions visibly on the wall. Another is to add them to the sprint backlog.
Also, make sure to follow up on the actions in the next retrospective. Did we complete the actions? Did they create an improvement?
13. Don’t wait for the retrospective!
Finally, don’t let the retrospective get in the way of continuous improvement. It’s not necessary to wait until the retrospective to raise issues or make suggestions. If something goes bad or someone has a great idea, it may well be better to deal with it there and then. Every time the team gets together is an opportunity to inspect and adapt!
With all the points above in mind, this is a structure I’ve found tends to work well for my teams:
- Start with a check-in exercise
- Go through the actions from the previous retrospective
- Gather opinions
- Identify what to focus on
- Agree actions
- Summarise the actions