During Agile Open Belgium I facilitated a session in search of retrospective exercises.
I always try to come up with new ways of looking for improvements. This way the retrospective doesn’t get to be a boring meeting.
Here’s the list of exercises we distilled:
- The classic: ‘What went well?’ / ‘What can we do better?’
Every team member categorizes his feelings about the previous sprint into these two categories.
At the end you can use dot voting to come up with a priority in the list of improvements.
- Creating a timeline
This exercise is done before the search for improvements. It is used to get everybody to focus on the same period and to get back into the mindset of the sprint.
What happened in the previous sprint, which timeframe, what did we work on,…
- Focus on one issue
If something important really went wrong, you might want to focus the entire retrospective on defining actions to prevent this from happening again.
- The starfish
A variation on exercise 1. Instead of the two categories, we use these five: Start Doing, Stop Doing, Keep Doing, More Of, Less Of.
The subtle differences between the categories help the team to think in a different way.
- Draw an emotional trendline
You need a timeline to start with. Each team member draws a trendline beneath it which represents their feeling during the sprint.
The more upwards, the happier. The more downwards, the more frustrated.
- Empty the mailbox
If your team has difficulties to remember things of the previous sprint, you can hang up a carton box in the team room. This is used to collect ideas for improvement.
In the retrospective, the box is emptied and each note is discussed and actions are defined.
- The line dance (sorry, I couldn’t come up with a better name)
When your team is divided between two options when discussing an improvement, you can use this technique to come to a decision.
Draw a line on the floor and mark one end with option nr.1 and mark the other end with option nr.2.
Then ask everyone to go and stand on a place on the line that represents their preference.
Main benefit is that the team immediately sees which option is preferred by the majority. (Thanks to Mary for sharing this)
At the start of the retrospective, write down a question on a flip chart and ask every participant to answer it one at a time.
This helps to open up the shy team members. If they have already spoken once, they will more likely speak again during the rest of the meeting.
- A poll
If you want to get an hones idea about the feelings of the team on a certain topic, for instance code quality, you can use an anonymous poll.
First write down the scale on a flip chart. Ex. 1= very bad, 4= very good.
Then ask everyone to write down a number on a post it that represents their feeling about the topic. Fold it and drop it in a hat.
Take the sum of all the numbers and divide it by the number of participants. If you did it right, you get a number between 1 and 4.
This gives you the general feeling about code quality at this time. You can repeat the same poll after some time to see if things evolved.
A great tip from Kris: Always use an even number as a scale, this way everybody has to choose a side, they can’t just stand in the middle.
- Giving flowers
Each participant gets a flower which they can give to a team member as appreciation for their work.
A great way to get your team closer together.
- Assign action points
Before leaving the meeting, make sure every action point has an owner, is prioritized and is visible (for instance on the task board).
The reason why people find retrospectives a waste of time is because actions never get done.
- Invite customer
Since the customer is closely involved with an agile team, inviting them to the retrospective can have a major added value.
In the end, we’re trying to improve the entire value stream, not only the work of the team.
I didn’t discover any new exercises, but got some great tips to do the known ones better. Thanks to all participants for their input!