95% of the time when I join a retrospective of a new team, often a team that doesn’t have a Scrum Master, it usually goes something like this:
First, the team quickly collects their happiness level. “On the scale of 1 to 5, how happy were you this Sprint?”
Then, the lead asks what the team can improve.
After a moment of complete silence, the same 2 or 3 people chime in with some ideas.
Most of the time those ideas are related to having too many meetings or bad user stories.
Sounds at all familiar?
That’s NOT how any retrospective is supposed to run.
I’m not trying to shame people leading these retrospectives, but rather I want to offer them and you 5 proven techniques and examples that will help you improve.
Keep watching to find out or read the article instead.
As we all know, many teams struggle with retrospectives. And I’m not just talking about Scrum teams.
Projects and releases often have post mortems and lessons learned that can be difficult to facilitate to get real results.
A very important point here is that retrospectives (or however you want to call them) have a very specific purpose: to help the teams improve.
When I hear developers complaining that retrospectives are a waste of time, I know immediately that they most likely are indeed a waste of time because they don’t lead to any real improvements.
There are a few reasons for why that is. I think I can make a whole video just about that.
However, in this video I’d like to give you some solutions and retrospective examples.
I’d like to first give you a good overview of what makes a good retrospective so that you know what to shoot for.
If you already know, you can skip right into the retrospective examples.
[convertkit form=3423219]
What makes a good retrospective?
So, what makes a good retrospective?
As I mentioned at the beginning, the whole point of a retrospective is to help the team improve.
It means that by the end of every single one of them you should have some ideas for potential improvements, some action items you might want to take.
Retrospectives are designed to be solution-oriented practical to-the-point discussions.
Technically, in every retro you make a decision as a team about what you can do better next time.
Other important aspect of a productive discussion here is the environment of trust.
Since the team will be discussing some negative topics, like what didn’t work so well last Sprint, they need to feel safe to share their thoughts.
This usually means that everyone knows that whatever is being discussed in this meeting is NOT going to be used against them.
They also need to know that what they say won’t be taken out of context.
And then even if there is a disagreement between team members, it will not ruin the relationships.
If you are an Agile leader, it’s your role to build that environment of trust.
One more important aspect is the sense of ownership and commitment.
What I mean by that is the team’s proactive participation in the retrospective.
It is about how THEY work, about how THEY collaborate, and how THEY can become more effective.
It is not for the Scrum Master’s or Team Lead’s sake.
So the team members need to be committed to improving as as team.
That way everyone on the team is involved in the discussion and contributes their ideas.
Of course, there are other aspects that can be considered, however, here I just wanted to highlight a few.
Now, let’s talk shop – a retrospective example to help you create fun and effective sprints.
Retrospective techniques
I’d like to stay away from popular retrospective techniques you most likely know about already such as Hot-Air Balloon, Racecar, Starfish, Sailboat, or Mad, Sad, Glad.
There are whole libraries of retrospective examples on every topic you can think of: Starwars, Spongebob, Pirates, and many many more.
Here is the thing – if you don’t know how to use them and how to facilitate discussions to build trust and ownership, these techniques are going to be a waste.
Firstly, while the team most likely will have some fun, they will not get any serious improvement ideas in.
Secondly, some team members will see it as silly and might consider retrospective to be sort of a team building activity, and hence, not as important compared to real work they need to do.
You can definitely use any of these techniques. Just remember that you need to have a strong structure and facilitation in place for them to bring you results.
I am not going to share retrospective techniques with you in this video.
What I want to give you here instead is an example of facilitating a productive discussion in a retrospective with some useful tools and practices.
Let’s go!
I’ll rely on a popular retrospective structure that was proposed in the Agile Retrospectives book by Ester Derby and Diana Larsen. But I’ll make them a bit more specific and practical for you.
1. Introductions and ice-breakers
When the meeting starts you want to spend a minute to get everyone ready for the upcoming discussion.
Retrospective is really “labor intensive” when done right, so you want your team to be in the right mindset.
If your team has been in back to back meetings all day, and you have your retrospective right after your Sprint Review, I recommend taking a 5 to 10 minute break.
At the start of the retrospective remind everyone why you got together: to find ideas for potential improvements, work more effectively going forward, and make the next Sprint more enjoyable.
If your team is fairly new, your should definitely run a short ice breaker exercise here. It can also be helpful in other situations to lighten the mood.
I have this video with 5 ice breakers you can use remotely and in person. Check it out for some ideas.
You can also use the Retrospective Prime Directive to remind everyone that it’s not about who is to blame, but about what we can do to improve
2. Reflecting on the Sprint
The next step to take is to spend some time reflecting on what happened in the past Sprint, or whatever is the period of time you are inspecting.
At this point you can give a quick reminder of what the Sprint Goal was and anything else that stood out during the Sprint.
Then help the team identify improvement opportunities and what practices worked and should be continued.
A big mistake that new retrospective facilitators make is to ask the questions “What went well and what can be improved?” with an intention of getting some answers right away.
If you do this, you will get very basic surface-level answers and will only engage a couple of people from the team.
Asking for immediate answers doesn’t leave room for team members to reflect and even simply remember what happened.
Even if your Sprints are just two-week long, it’s not that obvious to have a clear view of what was discussed on day one.
Give the team at least 3 to 5 minutes of silence to gather their thoughts and write down some notes.
It IS worth your time!
Need help with retrospectives?
Check my retrospective guides and templates. If you don’t know which one to choose, I recommend Structured Brainstorming.
3. Selecting the topics
The next very important step is to actually decide what you will focus the discussion on in the retrospective.
Another common mistake is to discuss every single item gathered during the brainstorming step.
This is a bad idea because it doesn’t give you enough time to discuss every topic and forces you to rush through without getting to the most important decisions the team needs to make during the retrospective.
Plus, it also often means that your retrospective runs overtime which will not be appreciated by the team.
You have to keep the discussion focused!
There are various things you can do here:
- Simple voting exercise, like dot voting
- Grouping notes and ideas that a related to reduce the list size
- Choosing topics based on which ones have the lowest score or the most negative notes
I’d recommend focusing on no more than 3 topics per retrospective, even if you have more time.
It’s better to have a good improvement in one area, then almost no improvement in many.
4. Facilitating the discussion
The next step is the hardest one for new facilitators because it requires some knowledge and experience in turning discussions in the right direction without interfering with the team’s thought process.
This requires practice, and sometimes, a good facilitation tool by your side.
Here are a few simple pointers for you to follow:
- Timebox the discussion to 5-8 minutes per round and keep tabs on time.
- Don’t be afraid to interrupt if you believe that the discussion went off topic or became unproductive.
- Always ask the questions like “What can we do?” to summarize the discussion.
There are lots of facilitation techniques that you can use to help you.
Sometimes just asking the right questions can create a more productive discussion.
I share lots of my personal tools, templates, and practices in my retrospective guides you can find in my store at store.scrummastered.com
There I give you step-by-step instructions on how to facilitate retrospectives, what questions to ask, how to organize the topics, and create focus on solutions.
I also share easy-to-use templates for remote facilitation proven to work. Check them out if you need some help on this.
5. Deciding on action items
You don’t want the retrospective to turn into a rant or airing of grievances.
While in the previous step you should have already driven the conversation towards actions with the “What can we do?” questions, here you want to get a commitment from the team.
It’s important that you leave enough time for this step and don’t rush the decision making just because you’re over time.
What you want to do is to get a clear unanimous confirmation from the team what action items they will take next Sprint and also get some volunteers to drive those actions.
One more common mistake from new facilitators is that they take on a lot of the action items on themselves because they truly want to help the team.
And also because no one wants to volunteer 😂
That’s not how it works – it’s the team’s responsibility to improve. You can’t do the job for them.
Let me also clarify the concept of “driving action items”.
If a team member have been assigned to an retrospective action, it doesn’t mean that they are now the only responsible for completing it.
The whole team is still responsible, it’s just that this specific person is there to remind, to organize if needed, and to drive attention to this action item.
The End
And this concludes a step-by-step retrospective example I wanted to share with you in this video.
Let’s recap. Here are the steps you can take to facilitate a simple retrospective:
- Introductions and ice-breakers to lighten the mood, give people a break and help them get into the right mindset
- Reflect on the Sprint with a simple brainstorming activity allowing 3 to 5 minutes of silent writing
- Select the topics you want to focus on by dot voting or grouping the notes
- Facilitate the discussion by keeping tabs on time, interrupting long rants, and focusing on action items
- Decide on action items by asking the team to commit and have a volunteer to drive them
Even though this video got quite long, I’ve just scratched the surface.
If you’d like to get even better results from your retrospectives, you should have some good tools in your toolbox. Consider checking out my online store for my guides, templates, and my book.