One of the things I enjoy doing is running retrospectives. I know, I’m a bit weird. No one likes meetings. Well, this is one important meeting in agile. Why? Because a retrospective allows your team to reflect on the last sprint and make changes. These can be any changes: process, code, metrics etc. With these changes, you can experiment and see what works and doesn’t work for your team. That’s what being agile is about – being able to change and cope with changes.
What is a retrospective?
A retrospective is a look back on the previous sprint(s) or piece of work that you’ve done. You want to deep dive into why things happened and how you can continue (the good) behaviours and stop (the bad) behaviours. It’s a chance for your team to regroup and connect to grow strong bonds. Retrospectives aren’t just about work – they’re about bonding in a team and having a great culture for everyone to speak up.
How do you run a retrospective?
The most basic retrospective is that you ask the following questions:
- What went well?
- What didn’t go well?
- Why?
These three questions are a start. You’ll learn what’s hurting the team and you can dive deeper to solve the issues. With a retrospective, you can drive changes to your agile process. Maybe someone says communication didn’t go well. You need to ask why. The answer might be because Bill didn’t know that Sandra had already fixed a bug, so they doubled up work. And then you ask why again. Because Sandra was sick on Tuesday, so she missed stand up and didn’t give an update. So, now you know the problem. How you solve it – is up to you.
There are so many “games” you can play in retrospectives. Some of them that I know are: “Mad, Glad, Sad”, “Start, Stop, Continue”, “Liked, Learned, Lacked, and Longed for”, and “Loved, Liked, Hated” etc. These games aim to get your team talking. For example:
Mad, Glad, Sad
You’ll have three columns on a whiteboard. Use post-it notes so that there’s no pressure on anyone to conform. Everyone has five minutes at the start of the retro to write down things that they’re mad, glad, or sad about.
- What are you mad about?
- What are you sad about?
- What are you glad about?
You’ll find that maybe some people write personal reasons. Maybe someone will write that they’re sad because they broke up. You know if they write that, they trust you and your team. Mostly, you’ll find that people write they’re happy that they finally got that massive feature out – or that they’re mad that the build server takes twenty minutes to build. These are all things you can use to improve your process and create change in your agile team.
How I run a retrospective
I tend to stick to the basic questions at the moment. What went well and what didn’t go well. I also like to do a happiness chart to get a feeling of how the sprint went.
What is a happiness chart?
It’s a chart that you can draw on your whiteboard (or A3 paper). Firstly you draw the axis. I like to do something like below. Here you can see the y-axis is the happiness and the x-axis is the time (in the sprint). Your team can mark points of importance to them to give a rough estimate of what caused them to change.
You can see that although the team is happy, the happiness over the sprint for everyone decreased. However, no one was unhappy – we just weren’t as happy as we were when we started the sprint. With this data, you can dig into why people became happy or unhappy. I find this handy because you gauge the whole team and it can be anonymous if you want. You can compare sprints and check if you have made improvements to your team’s wellbeing.
Retrospectives are for everyone
You should definitely make time for retrospectives. You need to be able to look back at your sprint and assess with your team what can be improved. But note: this is a team exercise. If you are a team lead or a manager you do not dictate what the team should improve or focus on. In fact, another person (from another team) should run the meeting. This, I’ve found is best to help separate the concerns because then the team leader becomes just a member of the team and does not dictate where the retro will lead. I look forward to hearing how you run your retrospectives and how you deliver change to your team.
Reposted on Medium.
Leave a Reply