Make your retrospectives fun with these games
In my team we conduct a retrospective every two weeks. On each occasion, we try to keep things fresh and stop the same format from killing our ability to spot and discuss a growing problem.
We were inspired by a paper on rotational cleaning and how regularly changing your cleaning process avoids bacteria strains resistant to your standard approach becoming common place. Although our usage is very different, the same theory can apply.
We begin each retrospective with a game to help mix things up, keep us energised, and make sure we’re alert and learning. Here are some you can try yourself.
The game: Trolling your team on the requirements
Dan wants a new car. Dan wants you to draw him his new car. All that he knows is he is looking forward to it and it’s going to satisfy all his dreams.
Take a whiteboard marker and design Dan’s new car for him.
Watch as the team make assumptions, draw incorrect conclusions, and only infrequently think to involve the original requester in the process. Maybe fast feedback and awesomeness come intuitively to you; I’ve a feeling for a lot of us this is something we have to remember to work at, hence this game!
How did the car end up? Was it exactly what the requester wanted? I suspect not, so highlight where assumptions were made and why they were incorrect. Ask the team what policies they could try out to make the next project a success.
For example, vague questions get vague answers. Try out a policy of deciding in the team exactly what is important to understand about the project, then be sure you get the answers you need to continue. A vague answer shouldn’t lead a team to decide (or assume) for themselves.
Did anyone ask if the requester liked the design before it was finished? Involve the requester in the design process.
Repeat the process. Now Dan wants a new house. Go!
The moral of the game:
We can all get a bit comfortable and complacent in our given domains, but it is important to remember that making assumptions about what a business user might want leads to a risk: the risk that the thing we build isn’t the right thing.
In my team, we found it did not come naturally to have an approach that restricted room for failure, so we decided it was a good idea for us to make feedback opportunities part of our standard process.
Definitely not the car of my dreams, despite the heart logo on the door which my team was sure I would love
Not far off the modernist home I would love to have – but what is with that fountain I didn’t ask for?
The game: Trolling your team on the estimates
Whiteboard markers out again. The task is to draw up to five cogs such that the cogs’ spokes multiply together to make X.
There should be a phase for planning and estimating how long the task will take, and then someone has to complete the exercise while you time them.
These cogs would make 8 * 6 * 6 = 288
We played for various values of X: 128, 34, 71, 260, 437
So how did your team do at estimating the time it would take? Try to discuss how people did in each instance. For example:
- What factors did the team take into account for their time estimate?
- For the first attempt, how much of that estimate was safety margin given no prior experience drawing cogs?
- Did they allow less time if they thought the number factored into a simpler equation?
- Does the number of factors really make a big difference to the time it takes to draw the cog?
We found it interesting to time how long was spent in the deliberation + estimation part of the task as well. Surprisingly, for a 37 second implementation task, it could take three minutes of deliberation before anyone even picked up a pen.
The moral of the story:
Estimation is tough! And estimates via triangulation aren’t always sensible. For instance, if people consider X=71 to be in the same class of problem as X=437 then they will scale up the time estimate and fail with disastrous effects. When we drew 437 spokes on a cog it became hard to keep track of how many we’d got up to, and the drawing had to start afresh at one point. Eventually fatigue set in and this cost further vital time that had not been factored in or considered.
As our team continued we found that, for numbers which were simple to factor, the team got more and more accurate at estimating. For more complex numbers we seemed to get worse. Often, this was because a big chunk of the work for more complex numbers was drawing a cog with many spokes (a cog with 437 spokes, for instance, because we couldn’t think of any way to factor that into smaller numbers). Yet even realising this we continued flip-flopping between vastly under and overestimating this type of task.
Any other ideas for retro games?
We have built up a good portfolio of fun games to play, to fill everything from 30 seconds to 30 minutes, but we would love to improve this collection. Share your ideas with us on Facebook, Google+ or Twitter.
Daniel Stoner, Senior Software Engineer