• Next: Chapter 6: Collaborating
• Previous: Root-Cause Analysis
• Up: Chapter 5: Thinking

in 99 words

Start with Kerth's Prime Directive. Everyone makes mistakes; the Prime Directive reminds us to support, not attack, our colleagues.

Have participants brainstorm ideas in six categories: enjoyable, frustrating, puzzling; same, more less. Write each idea on a card.

Next, place the cards on a whiteboard. Move the cards so the most similar are closest together. Everybody participates; nobody speaks.

Circle and name the resulting categories. Choose one, then brainstorm root causes and solutions. Pick one: it's your retrospective objective. Follow through in the iteration to come.

When retrospectives get boring, try other formats. This is just a starting place.

as haiku

the roses, flooded--
consternation, solution,
implementation

Commentary

Mistakes

Poster

Download this poster!

Full Text

The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright © 2008 the authors. All rights reserved.

Retrospectives

Audience

Whole Team

We continually improve our work habits.

No process is perfect. Your team is unique, as are the situations you encounter, and they change all the time. You must continually update your process to match your changing situations. Retrospectives are a great tool for doing so.

Types of Retrospectives

The most common retrospective, the iteration retrospective, occurs at the end of every iteration.

In addition to iteration retrospectives, you can also conduct longer, more intensive retrospectives at crucial milestones. These release retrospectives, project retrospectives, and surprise retrospectives (conducted when an unexpected event changes your situation) give you a chance to reflect more deeply on your experiences and condense key lessons to share with the rest of the organization.

These other retrospectives are out of the scope of this book. They work best when conducted by neutral third parties, so consider bringing in an experienced retrospective facilitator. Larger organizations may have such facilitators on staff (start by asking the HR department), or you can bring in an outside consultant. If you'd like to conduct them yourself, [Derby & Larsen] and [Kerth] are great resources.

How to Conduct an Iteration Retrospective

Anybody can facilitate an iteration retrospective if the team gets along well. An experienced, neutral facilitator is best to start with. When the retrospectives run smoothly, give other people a chance to try.

Everybody on the team should participate in each retrospective. In order to give participants a chance to speak their minds openly, non-team members should not attend.

I timebox my retrospectives to exactly one hour. Your first few retrospectives will probably run long. Give it an extra half-hour, but don't be shy about politely wrapping up and moving to the next step. The whole team will get better with practice, and the next retrospective is only a week away.

I keep the following schedule in mind as I conduct a retrospective. Don't try to match the schedule exactly; let events follow their natural pace:

1. Norm Kerth's Prime Directive

2. Brainstorming (30 minutes)

3. Mute Mapping (10 minutes)

4. Retrospective objective (20 minutes)

After you've acclimated to this format, change it. The retrospective is a great venue for trying new ideas. [Derby & Larsen] is full of ideas for iteration retrospectives.

Retrospectives are a powerful tool that can be damaging when conducted poorly. The process I describe here skips some important safety exercises for the sake of brevity. Pay particular attention to the contraindications before trying this practice.

Step 1: The Prime Directive

In his essay, "The Effective Post-Fire Critique," New York City Fire Department Chief Frank Montagna writes:

Firefighters, as all humans, make mistakes. When firefighters make a mistake on the job, however, it can be life-threatening to themselves, to their coworkers, and to the public they serve. Nonetheless, firefighters will continue to make mistakes and on occasion will repeat a mistake.

Never use a retrospective to place blame or attack individuals.

Everyone makes mistakes, even when lives are on the line. The retrospective is an opportunity to learn and improve. If an attendee feels threatened, they won't participate. The team should never use the retrospective to place blame or attack individuals.

As facilitator, it's your job to nip destructive behavior in the bud. To this end, I start each retrospective by repeating Norm Kerth's Prime Directive. I write it at the top of the whiteboard.

Regardless of what we discover today, 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.

I ask each attendee in turn if he agrees to the Prime Directive and wait for a verbal "yes". If not, I ask if he can set aside his skepticism just for this one meeting. If an attendee still won't agree, I won't conduct the retrospective.

If someone speaks once during a retrospective, she is more likely to speak again. By waiting for verbal agreement, you encourage more participation.

Step 2: Brainstorm

If everyone agrees to the Prime Directive, hand out index cards and pencils, then write the following headings on the whiteboard:

• Enjoyable

• Frustrating

• Puzzling

• Same

• More

• Less

Ask the group to reflect on the events of the iteration and brainstorm ideas that fall into these categories. Think of events that were enjoyable, frustrating, and puzzling, and consider what you'd like to see increase, decrease, and remain the same. Write each idea on a separate index card. As facilitator, you can write down your ideas too—just be careful not to dominate the discussion.

Ideas that are out of the team's control are fine.

People can come up with as many ideas as they like. Five to ten each is typical. There's no need to have an idea in each category, or to limit the ideas in a category. Any topic is fair game, from the banal ("more cookies") to the taboo ("frustrating: impossible deadline"). If people are reluctant to say what they really think, try reading the cards anonymously.

Ask people to read out their cards as they finish each one, then hand them in. Stick the cards up on the board under their headings. If you don't have a ferrous whiteboard, use sticky notes instead of index cards.

Wait until step 3 to group similar cards. It improves the flow of the restrospective.

If people have trouble getting started, describe what happened during the iteration. ("Wednesday, we had our planning session....") This approach takes longer, but it might be a good way to jump-start things when you first start doing retrospectives.

As people read their cards, others will come up with new ideas. The conversation will feed on itself. Don't worry if two people suggest the same idea—just put them all up on the board. Expect several dozen cards, at least.

As the conversation winds down, check the time. If you have plenty of extra time, let the silences stretch out. Someone will often say something that he has held back, and this may start a new round of ideas. If you're running out of time, however, take advantage of the pause to move on to the next stage.

Step 3: Mute Mapping

Mute mapping is a variant of affinity mapping in which no one speaks. It's a great way to categorize a lot of ideas quickly.

You need plenty of space for this. Invite everyone to stand up, go over to the whiteboard, and slide cards around. There are three rules:

1. Put related cards close together.

2. Put unrelated cards far apart.

3. No talking.

If two people disagree about where to place a card, they have to work out a compromise without talking.

This exercise should take about ten minutes, depending on the size of the team. As before, when activity dies down, check the time and either wait for more ideas or move on.

Once mute mapping is complete, there should be clear groups of cards on the whiteboard. Ask everyone to sit down, then take a marker and draw a circle around each group. Don't try to identify the groups yet; just draw the circles. If you have a couple of outlier cards, draw circles around those, too. Each circle represents a category. You can have as many as you need.

Once you have circled the categories, read a sampling of cards from each circle and ask the team to name the category. Don't try to come up with a perfect name, and don't move cards between categories. (There's always next time.) Help the group move quickly through this step. The names aren't that important and trying for perfection can easily drag this step out.

Finally, after you have circled and named all the categories, vote on which categories to improve during the next iteration. I like to hand out little magnetic dots to represent votes; stickers also work well. Give each person five votes. Participants can put all their votes on one category if they wish, or spread their votes amongst several categories.

Step 4: Retrospective Objective

After the voting ends, one category should be the clear winner. If not, don't spend too much time on it; flip a coin or something.

Discard the cards from the other categories. If someone wants to take a card to work on individually, that's fine, but not necessary. Remember, you'll do another retrospective next week. Important issues will recur.

Frustrated that your favorite category lost? Wait a month or two. If it's important, it will win eventually.

Ally

Root-Cause Analysis

Now that the team has picked a category to focus on, it's time to come up with options for improving it. This is a good time to apply your root-cause analysis skills. Read the cards in the category again, then brainstorm some ideas. Half a dozen should suffice.

Don't be too detailed when coming up with ideas for improvement. A general direction is good enough. For example, if "pairing" is the issue, then "switching pairs more often" could be one suggestion, "ping-pong pairing" could be another, and "switching at specific times" could be a third.

When you have several ideas, ask the group which one they think is best. If there isn't a clear consensus, vote.

This final vote is your retrospective objective. Pick just one—it will help you focus. The retrospective objective is the goal that the whole team will work towards during the next iteration. Figure out how to keep track of the objective and who should work out the details.

After the Retrospective

The retrospective serves two purposes: sharing ideas gives the team a chance to grow closer, and coming up with a specific solution gives the team a chance to improve.

The thing I dislike about iteration retrospectives is that they often don't lead to specific changes. It's easy to leave the retrospective and think, "Well, that's done until next week." If you're like me, the ensuing lack of action can be a little frustrating.

To avoid this frustration, make sure someone is responsible for following through on the retrospective objective. It's not that person's job to push or own the objective—that's for the whole team—but it is his job to remind people when appropriate.

Allies

Informative Workspace

Iteration Planning

To encourage follow-through, make the retrospective objective part of the iteration. For general behavior changes, such as "switch pairs more often," consider adding a big visible chart to your informative workspace. For specific actions, such as "improve database abstraction layer," create task cards and put them in your iteration plan.

Questions

What if management isn't committed to making things better?

Although some ideas may require the assistance of others, if those people can't or won't help, refocus your ideas to what you can do. The retrospective is an opportunity for you to decide, as a team, how to improve your own process, not the processes of others.

Your project manager may be able to help convey your needs to management and other groups.

Despite my best efforts as facilitator, our retrospectives always degenerate into blaming and arguing. What can I do?

This is a tough situation, and there may not be anything you can do. If there are just one or two people who like to place blame, try talking to them alone beforehand. Describe what you see happening and your concern that it's disrupting the retrospective. Rather than adopting a parental attitude, ask for their help in solving the problem and be open to their concerns.

If a few people constantly argue with each other, talk to them together. Explain that you're concerned their arguing is making other people uncomfortable. Again, ask for their help.

If the problem is widespread across the group, the same approach—talking about it—applies. This time, hold the discussion as part of the retrospective, or even in place of it. Share what you've observed, and ask the group for their observations and ideas about how to solve the problem. Be careful: this discussion is only helpful if the group can hold it without further arguing.

If all else fails, you may need to stop holding retrospectives for a while. Consider bringing an organizational development (OD) expert to facilitate your next retrospective.

We come up with good retrospective objectives, but then nothing happens. What are we doing wrong?

Your ideas may be too big. Remember, you only have one week, and you have to do your other work, too. Try making plans that are smaller scale—perhaps a few hours of work—and follow up every day.

Ally

Slack

Another possibility is that you don't have enough slack in your schedule. When you have a completely full workload, nonessential tasks such as improving your work habits go undone. (The sad irony is that improving your work habits will give you more time.)

Finally, it's possible that the team doesn't feel like they truly have a voice in the retrospective. Take an honest look at the way you conduct it. Are you leading the team by the nose rather than facilitating? Consider having someone else facilitate the next retrospective.

Some people won't speak up in the retrospective. How can I encourage them to participate?

It's possible they're just shy. It's not necessary for everyone to participate all the time. Waiting for a verbal response to the Prime Directive can help break the ice.

On the other hand, they may have something that they want to say but don't feel safe doing it. [Derby & Larsen] have some good suggestions about how to incorporate safety exercises into the retrospective. You can also try talking with them individually outside of the retrospective.

One group of people (such as testers) always gets outvoted in the retrospective. How can we meet their needs, too?

Over time, every major issue will get its fair share of attention. Give the retrospective a few months before deciding that a particular group is disenfranchised. One team in my experience had a few testers that felt that their issue was being ignored. A month later, after the team had addressed another issue, the testers' concern was on the top of everyone's list.

If time doesn't solve the problem—and be patient to start—you can use weighted dot voting, in which some people get more dot votes than others. If you can do this without recrimination, it may be a good way to level the playing field.

Another option is for one group to pick a different retrospective objective to focus on in addition to the general retrospective objective.

Our retrospective always take too long. How can we go faster?

It's okay to be decisive about wrapping things up and moving on. There's always next week. If the group is taking a long time brainstorming ideas or mute mapping, you might say something like, "Okay, we're running out of time. Take two minutes to write down your final thoughts (or make final changes) and then we'll move on."

That said, I prefer to let a retrospective go long and take its natural course during the first month or so. This will allow people to get used to the flow of the retrospective without stressing too much about timelines.

The retrospective takes so much time. Can we do it less often?

It depends on how much your process needs improvement. An established team may not need as many iteration retrospectives as a new team. I would continue to conduct retrospectives at least every other week.

If you feel that your retrospective isn't accomplishing much, perhaps the real problem is that you need a change of pace. Try a different approach. [Derby & Larsen] has many ideas to try.

Results

When your team conducts retrospectives well, your ability to develop and deliver software steadily improves. The whole team grows closer and more cohesive, and each group has more respect for the issues other groups face. You are honest and open about your successes and failures and are more comfortable with change.

Contraindications

The biggest danger in a retrospective is that it will become a venue for acrimony rather than for constructive problem solving. A skilled facilitator can help prevent this, but you probably don't have such a facilitator on hand. Be very cautious about conducting retrospectives if some team members tend to lash out, attack, or blame others.

The retrospective recipe described here assumes that your team gets along fairly well. If your team doesn't get along well enough to use this recipe, refer to [Derby & Larsen] for more options and consider bringing in an outside facilitator.

If only one or two team members are disruptive, and attempts to work the problem through with them are ineffective, you may be better off removing them from the team. Their antisocial influence probably extends beyond the retrospective, hurting teamwork and productivity.

Alternatives

There are many ways to conduct retrospectives. See [Derby & Larsen] for ideas.

I'm not aware of any tools that allow you to improve your process and improve team cohesiveness as well as retrospectives do. Some organizations define organization-wide processes. Others assign responsibility for the process to a project manager, technical lead, or architect. Although these approaches might lead to a good initial process, they don't usually lead to continuous process improvement, and neither approach fosters team cohesiveness.

Further Reading

Project Retrospectives [Kerth] is the definitive resource for project retrospectives.

Agile Retrospectives [Derby & Larsen] picks up where [Kerth] leaves off, discussing techniques for conducting all sorts of agile retrospectives.

"The Effective Post-Fire Critique" [Montagna] is a fascinating look at how a life-and-death profession approaches retrospectives.

• Next: Chapter 6: Collaborating
• Previous: Root-Cause Analysis
• Up: Chapter 5: Thinking