James Carr

I’m gearing up to put together a retrospective for my team at my current client site, and I’ve been both thinking about and reading over notes from previous retrospectives I’ve either sat in or facilitated. Looking over a lot of these notes, especially from the worst ones, I’ve noticed an emerging pattern of behavior that can either make or break a retrospective. Here’s a few that I think are the most important.

1. Retrospective Belongs to the Team

   This is possibly the most important observance I’ve noticed… retrospectives are only effective if they truely belong to the team. This means that it should only be attended by the team and only the team can pick a goal and how they’re going to follow up on them. Management shouldn’t attend the retrospective imho as they can cause interference, step in, or require metrics to be collected. Several retrospectives I participated in at my previous client had the manager constantly cut people off or tell them that the goal they’re proposing won’t work and refuse to let it be considered. These retrospectives were the most useless in my opinion and we never accomplished anything.

2. Don’t Let It Become a Whine-fest

   Retrospecting is about inspect and adapt… about looking at our experiences over the past and using root cause analysis to find causes and how we can improve in the future. However, if there is plenty of negativity in the past, it can be easy to succumb to “crying over spilt milk” without coming up with any real solutions. And nothing is worse for a team then to spend an hour in a room listening to each other bicker without any from of constructive activity… it will leave the team feeling down rather than up. Therefore aim to keep the retrospective on track to discuss the facts and observances and put emphasis that the past is only for concrete experience to draw ideas from. Problem solving activiities should be given more focus than pouring over historical data.

3. Activities Are Better

   I’ve sat in on hundreds of retrospectives, both with activities and without. On the outset, the no-nonsense, just talk about “what worked, what didn’t, what to improve” sounds good, simple, and to the point. However, my experience indicates these were amongst the lowest in terms of effectiveness. For starters I think it keeps people locked into a “this is a meeting” mentality and prevents thoughtful activity. Hell, one place I was at just put a word document up with headings titled “What Worked, What Didn’t Work, Action Items” in which Action Items were items the manager would enter into Rally Project Management and assign to people to work on.

   I’ve found that activities often keep people engaged. In a meeting someone can get by by sitting in front of their laptop staring at the projector, with activities they’re constantly involved and not given time to disconnect. Additionally, I find the care freeness (or even fun) of activities helps break down some subtle communication barriers and makes people feel more free to speak their minds.

4. Pick Only One Goal

   In theory picking multiple goals sounds great right? We’ve identified all these impedments and road blocks in our team,process, or environment that really need to be addressed. Why don’t we just tackle ALL of them rather than ignore them so we can work on removing all of them? This is long the same lines of the theory that maximizing Work-in-Progress maximizes effeciency and we all know that this often fails. LIkewise, by maximizing the number of goals that you have for an iteration you run the risk of context switching too much (not to mention all the focus you’ll already have towards the work you’re doing during the iteration) that the team will lose track and quite possibly not make any headway towards any of the goals listed.

   Therefore, limit your Work-in-Progress as a team by selecting one (and only one) goal for the team to work towards during the next iteration. Maybe you’ll complete it in one day. Maybe you’ll complete it by the end of the iteration. Maybe you’ll make progress on it and discover in the next iteration that you uncovered deeper issues that need to be addressed.

5. Follow Up

   One of my biggest mistakes I ever made as a facilitator was failing to help the team follow up on goals… I assumed you could just let the team form a goal, work out how they would accomplish it, then just let them leave the room with it to schedule into their iteration and complete. Boy was I wrong. Working towards that goal can possibly even grow future retrospective topics, or like I mentioned previously uncover more serious or deeper issues the team needs to address. Failing to follow up can leave the team with a slew of goals they never complete or superficial goals that only kick some dirt over the issue. So it’s good to recap on the goal that was formed as part of establishing historical data near the beginning of the retrospective and let it help drive new ideas or delve deeper if it wasn’t completed. Often times you can find incomplete goals correlate to the iteration… for example if it wasn’t reached because there wasn’t enough time to work on it, maybe there’s not enough slack in the iteration?

Again, out of all these, I’d have to say the most important is number one: the retrospective belongs to the team. This is an activity for the team by the team to help them inspect and adapt their process and shouldn’t be something enforced upon them or led by their manager. I ask all ScrumMasters out there to take special care if you facilitate the retrospective… in my opinion you really shouldn’t, but if there’s an absence of facilitation skills you might need to. If this is the case, remember your position… you are not a manager and therefore should not use this to dictate goals to the team. Stay as neutral as possible and at all costs do not allow yourself to become the owner of a solution, it needs to belong to the team and the team needs to make whatever needs to happen happen. If they need to schedule a task into the iteration, let them do it rather than do it for them.

Likewise, as a facilitator it is of utmost importance to remain neutral. When I facilitate teams I am on I try to refrain altogether from involvment. Also remember as facilitator it’s your job to facilitate the discussion, not drive it or offer solutions. I’ve facilitated a retrospective once where someone called on my expertese with fitnesse to help them solve a recurring fitnesse problem they were having. Sadly, I offered solutions. Looking back, I should have suggested that they come up with a goal, and if they needed help they could come seek me out when I had my developer hat on out on the floor. Further, I often find that when a facilitator from the team participates, they often drive the entire retrospective. Either their ideas lead for the rest to follow (even if they participate last) or the teams participation might fall on deaf ears. I once watched a friend of mine facilitate a retro for our team and draw out a huge value map… at each time two or three pople would say what they thought the cause was, then he’d say “well, I think it’s really this…” and write out his own idea in the map without taking into account what the team said. When I called him out on this he couldn’t believe he did that.

Overall, keep in mind the retrrospective is for finding solutions, not problems. Keep it on track, listen, and help guide the teams to introspect within themselves and find the solutions they need. Most importantly let them do the decision making and above all use the retrospective as their own activity to get better.

This week I got to have someone from another team who has been taking part in our “retrospective facilitators” group facilitate my team’s retrospective. He had started out using the framework from the Agile Retrospectives book and with a little help from me, but this week I got to see how he had evolved the format in a way I didn’t expect.

What he had done was apply a theme to the activities that made them fun and coherent. He used a news paper/reporting theme with the following structure:

• Set Up: Paint the Iteration
• Gather Data: Iteration Headlines
• Generate Insight: Investigative Reporting
• Decide What To Do: Read All About It
• Wrap Up: Plus / Delta

I was throughly impressed… the format was fun and enjoyable yet still tied back in a kind of abstract way to the activities outlined in the Agile Retrospective book. One of his teammates also told me about one retrospective where he used a CSI theme… hehehe. I must say… it’s always a great feeling when you teach someone something, then later they teach you.

So today I tried something along similar lines… using a car theme. The iteration started with asking participants what kind of car they would use to describe the iteration. Then, transparently moving into the gather data phase, ask them why they chose that car. From here, we did the Learning Matrix, but with a twist… rather than Things to Keep, Things to Change, Ideas, and Praise, we used Showroom, Junkyard, Research and Development, and Car and Driver Awards.

From these two retrospectives I’ve found that applying a theme seems to open up participation more… people chuckle a bit and seem to be more relaxed. Best of all, it’s fun dreaming up new themes and keeps people throughly entertained… and it’s hard to get bored with the activities because they’re always approached differently, giving them a fresh feel.

Just a reminder… it seems to be best to send out a small agenda of the activities before hand so people have time to think about something to describe the iteration with. I tried a Pirate theme on Talk Like a Pirate Day without some advance notice and everyone was a bit confused on how exactly a pirate would describe the iteration. Unfortunately no one stated that they “Plunder’d dem storahs” that iteration.

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!

Lately we’ve been trying to improve our retrospective format, moving away from the as hoc “More Of, Same Of, Less Of” and into something more engaging and useful. For this goal, I’ve been applying the pattern outlined in the excellent Agile Retrospectives book:

1. Set The Stage
2. Gather Data
3. Generate Insights
4. Decide What To Do
5. Wrap Up

The initial feedback i got on Set The Stage was that it felt like a waste of time… this usually includes activities like asking participants what is one word they’re thinking of coming into the retrospective or other things to get them into focus mode. Since we’re pressed for time and didn’t get much value from this activity, we dropped it in favor of a just quick overview of the agenda.

Anyhow, after facilitating a few retrospectives using this format for my team, we branched out and tried it with other teams. The idea we’ve been having is to have someone from another team facilitate a team’s retrospective, allowing all members to participate rather than one being somewhat removed. This week I facilitated retrospectives for three teams, two of which had customers joining over teleconference from the other side of the country. The results were pretty interesting and below I have included my notes of the last two that I did.
Read More »