One of the biggest challenges of a ScrumMaster is to conduct retrospectives.
Running one retrospective is easy: Every conscientious ScrumMaster most likely has read the retrospective bible, Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen (and if you haven't, I highly recommend that you do so straightaway). So you just need to follow the guidelines and your retrospective will go smoothly. Right?
However, if you have, as most people do, two-week iterations, you will hold, more or less, 20 retrospectives in a year. Running such a number of retrospectives becomes an interesting challenge. How do you keep your team focused during retrospectives? How do you avoid retrospective monotony? How do you find ideas for a different and original retrospective in each iteration?
In this article, I will present a concrete exercise that will, I hope, boost your next retrospective. Turn the tables is based on the traditional retrospective structure described in Derby and Larsen's book:
- Set the stage.
- Gather data.
- Generate insights.
- Decide what to do.
- Close the retrospective.
"Turn the tables" will mainly stand out in phase 2 (gather data) and phase 3 (generate insights), by coming up with an original idea. Other steps can easily be chosen among various classic activities. In this article, I will give examples of activities used to design a consistent retrospective.
Turn the tables
Number of participants: three to eight people
Materials: green and red sticky notes/cards, a whiteboard or a paperboard, markers
Time required: one hour
1. Set the stage.
If the team is new to doing retrospectives, do not hesitate to remind everybody of the retrospective principles (secure space to speak, exercise to improve team, etc.).
Then you can use a "check-in" activity. It's an easy way to start and give everybody the occasion to say a word or two. It also provides a good indicator of team's mood. For instance, I ask each team member how he felt the current iteration went, on a scale from 1 (bad) to 5 (really good). Then I draw the results on the board, and I take a picture of it to send to the team after the retrospective.
2. Gather data.
Ask each team member to write a maximum of two things on the red and green stickies that went well during the sprint, and two things that could be improved. Ask people to write only one or two words to best describe their point.
It's important for participants to follow these instructions. If people ask you why, or if they complain about the constraint, invite them to play the game — they will figure it out.
If you have the materials, it's better to write good things on green cards (or sticky notes), and things to be improved on red. This will improve the visual feedback. Use markers and write it big enough for everyone to read.
Once everybody's done, ask people to give their two red cards to the person on the left, and the two green cards to the person on the right.
At this point you can explain why it was important to write only one meaningful word on the card: because someone else is going to present your card!
Ask people to briefly present their coworker's card (the card they have in their hand). They must try to put themselves in the shoes of their colleague. This exercise has several benefits: First of all, it's funny (you'll see). Also, it's interesting to see and try to explain what others think and how they felt during the sprint. Sometimes people work closely each other but don't talk much. In multidisciplinary teams, it can happen that developers misrepresent the tester's job, or the product owner's job, and vice versa.
This exercise can improve team cohesion and reduce misunderstandings.
After each card presentation, ask the original card owner to rate the accuracy of the explanation on a scale from 1 ("That was absolutely not my thought") to 5 ("I couldn't have said it better"). Draw the ratings on the board — they're a good indicator of the team's level of cohesion and communication.
Sometimes people are frustrated because what was said wasn't exactly how they would have presented the issue. If needed, the original card writer can complete the description, but it should be done briefly.
This step ends when all the cards have been presented.
You can ask people to start with the green cards, run the talks clockwise, and once every green card is done do the same thing with red ones. Or you can alternate one green card and one red card per person. It's your choice — but don't forget to watch the clock! As a ScrumMaster, you're often the timekeeper.
3. Generate insights.
After each card has been presented, ask people to give the two red cards in their hands to the person on the left (red cards should not return to the original writer). Green cards can go to the middle of the table.
Now participants have red cards, written by someone else, in their hands. Ask each team member to suggest an action to improve what's written on the red cards in front of them. At this point everyone can participate, but it's important that the first idea come from the card handler. Indeed, it's not rare that the best solutions come from someone else, someone with a new point of view, someone with a little more perspective. Sometimes the writer of the card has been so focused that he or she has missed an obvious solution.
Write all actions and suggestions on the board, using any format you choose. For instance, I like the "short subjects" activity (activity 7.4, p. 112 of Derby and Larsen). And recently I used this format:
4. Decide what to do.
Right now, you have a bunch of actions on the board. You should select two or three to take in the next sprint. Don't select too many actions, especially if they take time. Only take actions your team is able to do. If you don't, in retrospective after retrospective team members will ask what's the point of selecting actions if they never achieve them.
If you have lots of actions written down, use any technique to choose two or three. For instance, people can use three votes each for their favorite actions, and you can select the two or three that receive the most votes.
Even though it can be frustrating at the beginning, the advantage of the limited number of cards per person is that you shouldn't have too many actions chosen at the end.
5. Close the retrospective.
Close the retrospective by thanking everybody for their participation, and choose a closing activity. For instance, you can use ROTI (Return on Time Invested, activity 8.5, p.126 of Derby and Larsen). ROTI is an indicator of how participants perceived the time invested in the meeting, on a scale from 1 ("no benefit received for time invested") to 5 ("I couldn't have spent my time better").
Feel free to take a picture of your ROTI. You can send it to your team after the retrospective.
"Turn the tables" relies on experienced activities, and it can really bring fun in your routine. It isn't revolutionary, but if you feel like your team is too comfortable or a little bored, it's definitely worth a try. I've used it a couple of times, and the feedback from participants was positive every time.
I've noticed the following benefits:
- Improved communication among team members
- Observable and improved team cohesion
- Reduced misunderstandings
I recommend using this activity when:
- The team is not too large (it keeps the meeting short)
- There are communication problems in the team
- There is tension between team members
- You want to reduce the number of cards/sticky notes
- People don't know each other very well (at the beginning of a project, after two or three iterations)
By "turning the tables," people try to be in other team members' shoes. Sometimes that's sufficient to solve issues or reduce differences. It always leads to really good interactions, and I've noticed that actions popped up naturally in the discussion.
So why not try it for your next retrospective? If you do, don't hesitate to send in your feedback!