Keeping Retrospectives Fun

At the May DC Scrum user group, we had a workshop on retrospectives. We covered six different techniques to keep retrospectives fun.
For all the techniques we followed this structure:

1. Set the stage: This entails ensuring that everyone feels safe to express their opinions. A good way is to start out with the prime directive:
   "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand"
2. Gather data: This is where we create a shared pool of data to ground the retrospective in facts instead of opinions.
3. Generate insights: This is where we observe patterns, determine root cause, and build a shared awareness of the situation.
4. Decide what to do: This is where we move from discussion to action and come up with a plan to resolve the top 2 or 3 items.
5. Close: This is where we review the findings, reiterate the action items, and appreciate everyone’s participation. 

The six techniques covered where:

1. Draw me a picture
2. Silent retrospective
3. The timeline
4. Team radar
5. 5 Whys 
6. and a special bonus technique called Retrospective Cookies courtesy of Adam Weisbart.

Timeline Retrospective

The Timeline Retrospective is a technique used to reflect back on major events that occurred during a Sprint or a Release

The process is as follows: 

1. Silently write down on sticky notes the major events that occurred
2. Create a single timeline on a wall 
3. One by one, layout the notes in order of occurrence on the timeline
4. Place positive events above the timeline and negative events below the timeline
5. Discard duplicates
6. Have one person walk through the final timeline
7. One by one, rank the events on the timeline using dot voting 
8. Identify actions for the highest ranked events
9. Rerun the time line with the actions and see what changes and if you get the desired outcome. 

 
Adapted from: Putting the fun back in your retrospectives @ Agile2011

Draw me a picture

Draw me a picture is a retrospective technique that can be used when people are tired of the same old routine and when verbal communications are failing.

The process is as follows:

1. Ask the attendees to silently reflect on the on the events of the last iteration or release 
2. Ask them to draw a picture reflecting their feelings 
3. Place the picture on the wall
4. In turn, let each participant describe their picture and provide a title
5. Try to observe patterns to highlight significant events or impediment

Adapted from: Putting the fun back in your retrospectives @ Agile2011

Captions

Captions is a retrospective technique that can be used as a collaborative and safe way to share feelings. The technique is fun and the results can be very insightful and hilarious at the same time.

The process is as follows:

1. Announce a specific topic for discussion 
2. Each team member gets n number of index cards where n is the number of team members. The cards are numbered sequentially in each stack. 
3. Individually, on card #1, members draw a picture to illustrate the topic at hand 
4. The decks are passed to the right 
5. On the new deck received from the left, members study the picture on top, then move the card to the bottom of the deck. 
6. On the next card, members write down a caption for their interpretation of the picture they just saw 
7. The decks are passed to the right 
8. On the new deck received from the left, members read the caption, then move the card to the bottom of the deck 
9. On the next card, members draw a picture based on the caption they just read 
10. This process is repeated for several rounds until each stack is back at card #1 
11. Members take turns laying out the decks and reading out and sharing the results with the team 

Note: If the number of team members is even, then start with drawing a picture, otherwise, start with writing down a caption.

Adapted from: Putting the fun back in your retrospectives @ Agile2011

The 5 Whys

The 5 whys is a retrospective technique that can be used when the team needs to focus on a specific symptom that does not have an obvious solution. The goal of the 5 whys is to clearly understand the situation and not necessarily to solve the problem.

The process is as follows:

1. Write the problem statement clearly and concisely on the board.
2.  Divide the team into groups of at least 3 but not more than 5. 
3.  In each group, individually answer why did this happen? Number your answer as #1.
4.  Individually answer why did #1 happen? Number your answer as #2.
5.  Individually answer why did #2 happen? And so on until you have around 5 answers or can’t come up with more meaningful answers (try to have at least 3 answers).
6.  Each individual places their chain of responses in a column below the problem statement. The group then discusses the individual answers and tries to find common patterns.
7.  The group consolidates the chains into a single chain.
8.  If necessary, the team consolidates the chains into a single chain.

Participants should focus on exploring the immediate cause of the symptom rather than attempting to immediately jump to a root cause. The intermediate reasons often spark ideas within the group that would otherwise be overlooked.

While this exercise is typically applied against problems, this same technique can also be used to discover what led a team to achieve exceptional success in one area.

Adapted from: Putting the fun back into your retrospectives @ Agile2011

Heartbeat Retrospectives to Amplify Team Effectiveness

At Qcon London 2007, Boris Gloger described a 6 step process for performing retrospectives:

1. Security – Do not do a retrospective in a stressful environment. Make sure that no one is to blame. Regardless of what we discover, we understand and believe that everyone did the best job they could given they knew at the time, their skills, abilities and resources and the situation at hand.

2. Collect facts - Have a timeline with post-its about experiences of important events. Have the team members tell a short story of every event that is important from their point of view. Concentrate on facts and not emotions.

3. What went well? – Again, post what went well.

4. What could be improved? – Post what could be improved. Environment, skills, resources, hardware. Gather new ideas.

5. Who is in control? – All the ideas are coming from the team. Who is in control of improving what is discussed. Is it the team or the organization?

6. Prioritize – The goal is to improve the next iteration immediately. Have a team backlog that includes things the team must work on besides the product backlog (training, resources, etc.) Have an impediment backlog that includes organizational issues that impedes the team Prioritize and sort them then and add stories to the next sprint.

The retrospective should take between 10 to 90 minutes. It should not be held in the team room, but instead in a dedicated and neutral room that provides a secure environment. Attendees should include the entire team and whomever else the team would like to include.

This presentation is available on InfoQ at http://www.infoq.com/presentations/Heartbeat-Retrospectives-Boris-Gloger

Agile Restrospectives – Making Good Teams Great!

Esther Derby and Diana Larsen gave a presentation at Google Tech Talk about agile retrospectives. They explained how retrospectives are tied to the agile practices of inspect and adapt. It fits into the feedback cycle, looking at what you are doing, see if it is working or whether you need to do some changes and try things in a different way. Retrospectives address effectiveness of methods, engineering practices and team work.

They then describe 5 steps of retrospectives:

1. Set the stage: get everybody’s head in the game.

2. Gather data: what happened and how we responded.

3. Generate insights: make meaning of the data.

4. Decide what to do: same, differently, or try new things.

5. Close the retrospective.

Retrospectives are ongoing and a linked process that flows naturally at the end of each iteration and into the planning part of next iteration. People think that they don’t have time for all of this, but these 5 stages can be done in about an hour. They recommend that you don’t skip these stages as you might compromise the results.

Next they cover each stage in details:

1. Set the stage: Specify a goal on what we are going to look at and an agreement on how we will work together.

• a. Have a goal like let’s look at what’s working and what’s not working. This is good to start out with, but after a while it becomes boring. So then set a new goal like let’s look at how well we are applying coding standards, refactoring, xp practices, etc…

• b. Set a working agreement: Inquiry rather than advocacy, Dialogue rather than debate, Conversation rather than argument, Understanding rather than defending

2. Gather Data: Think together as a group and look back over the iteration. Create a timeline and put up events that are important. Try to have a common understanding of the what went on and get a fuller picture of what happened. Also add an emotional graph tracking energy (high, medium, low) along with the events (avoid using the word ‘feeling’).