James Carr

Tonight I have more stories and thoughts to share from the trenches of facilitating Agile Retrospectives. As we’ve continued a few more iterations of participating in better organized retrospectives, I’ve noticed that there are a few interesting patterns that have emerged that a lot of retrospectives seem to follow. I’ll kind of avoid the Wrap Up phase for these, as the Wrap Up phase tends to focus more on how to improve the retrospective or ideas for the next retrospective.

The “What Happened?” Retrospective

This is a retrospective where we come into it asking “What happened? What was interesting this iteration?” This type of iteration usually begins with a setup activity of weather report or one word to describe the iteration, where participants will either state their feelings of the iteration with one word or a weather report like “Sunny” or “Slightly Stormy”. Lots of positive feedback identifies more of a “Great Iteration” which I’ll cover later, or an iteration with some issues that arose.

We usually Gather Data in this kind of retrospective with either an Iteration Timeline to identify events where time mattered or use Mad, Sad, Glad to help us identify significant events that made us mad, sad, or glad. The latter activity works well… we break up into small groups or pairs for a time boxed period of time to identify events both as a team and as individuals.

Once we post all our sticky notes or (my personal favorite) color coded sticky index cards on the board, we gather around and work together to identify Patterns and Shifts to see what events are related, what events caused other events, and briefly discuss our feelings and thoughts on these issues. For example, one iteration we had a lot of cards under Sad and Mad that were related to a failing in communication… we discussed what happened, and why. We got to see viewpoints from other perspectives regarding it.

From there we participate in a Circle of Questions activity, where we all sit in a circle and, one at a time, ask the person to our left a question regarding something that was posted, as well as ask what they think we could do to improve. After a few rounds of the circle we usually come to a goal of sorts.. something we can help plan for the next iteration to improve. Building off the communication example, this can come about by identifying four important keys to communication that make it meaningful… something we can use a radar to track daily or at the beginning of the next retrospective. When we have a goal that could be accomplished in the next iteration through tasks, we do a Retrospective Planning Game, where we come up with tasks to do towards completing a goal, size them, and prioritize them as if it was an iteration planning game. Throughout the iteration we can pick these tasks up and work on them as time allows, schedule them into the iteration, or just pick them up if they relate to a story.

This is a converse of another type of retrospective, where the iteration went well.

The “Awesome Iteration” Retrospective

This is a retrospective where, when participants are asked to describe the iteration in one word, you end up seeing things like:

• Awesome
• On Schedule
• Exciting
• Fast
• Productive

Since the iteration went great, why not build off of the “why” it went so well? So we follow with the activity Locate Strengths. This has followed a bit of a pattern we’ve done before… we break into small groups or pairs and jot down as many strengths that we think contributed to a good iteration, maybe even including a bit of praise here and there.

We then get back together and write on a whiteboard what strengths we identified, with a brief discussion of each, maybe even including an example or two from the iteration. For example, someone might point out collaboration or communication and explain how they were confused about a story, contacted their customer, and then worked with the customer to identify domain logic that was a key to successfully completing the story quickly. Lots of praise usually happens here for jobs well done.

Now that we’ve located strengths and agree that these are very important key ingredients for a great iteration, we want to improve so we can continue to have great iterations. We then Vote With Dots giving each person a number of votes to vote on what strengths they think are the most important, and then narrow them down to either two or one to take and try to improve upon.

I’ve found any Decide What To Do activity works here… the key is to build off previous experience or knowledge to help the team reinforce that strength.

The “How Did We Do?” Retrospective

This type of retrospective follows a retrospective where goals were set forth… we set a goal, and now we want to know how we did achieving that goal. I’ve found that a great gather data activity for this can be the Radar activity… basically you define four key concepts of that goal and have each team member vote from 1 to 10 on each concept… using the average to generate a radar graph of where the team is at on that goal, perhaps revisiting in successive iterations to see if the radar expanded (identifying improvement) or shrunk (identifying decline).

An interesting variation here is to maybe come up with averages for both developers and customers… although you must use great care not to pit the two against each other, it helps see how both groups perceive progress on that goal. A Radar helps visualize this rift in perception and aids in discussion on the difference of opinion.

This is followed in the generate insights phase with an activity that helps explain the data on the radar. Five Whys might help… so does Short Subjects and Force Field Analysis. The idea is to identify what aided in moving towards or accomplishing the goal, as well as what hindered progress towards it.

Sometimes deciding what to do feels awkward here… if the team accomplished or even exceeded the goal, what is there left to do? Any Decide What To Do activity works well here though, either something specific to help us reach the goal if we haven’t, and if we have, something to help us improve or maintain it.

Keeping Track

The hard part is keeping track of what came out of these retrospectives… sometimes as developers we hate documentation! However, we need something to help us keep track of what has happened, perhaps to use in future retrospectives. Take pictures of any graphs, charts, or time lines so that you can look back on them. Try to keep a notebook or a wiki that summarizes the retrospective. Especially when we use the team radar, we need data we can look back on from previous retrospectives to put things into perspective.

Anyway, hope this post has been helpful for those of you out there working on facilitating your own retrospectives, and I’d love to hear of any experiences or interesting patterns you might have noticed as well… and if you have any advice, I’d like to hear it too!

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

This entry was posted on Thursday, September 4th, 2008 at 10:06 pm and is filed under Agile Software Development, retrospectives. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.