Chapter Six. Retrospective Exercises

Owl picked up Singed-Tail’s copy of Swine in Wine and quickly became intrigued. It wasn’t the recipes themselves but the overall structure of the cookbook that caught his immediate interest. Leafing through it, he realized that the cookbooks he’d used had had the same structure as this book, with the first part including general information, the second part containing recipes, and the final section presenting special topics and suggestions on what the reader might explore next.

It struck Owl that this three-part format let a reader browse while planning a menu. Although he knew that cookbook authors do not expect each and every recipe to be read or every dish to be prepared, he realized the value in a reader being able to look through all the recipes. Each cook is expected to use his or her own imagination, and to consider the guests’ preferences, the available ingredients, the desired mood of the meal, and so forth, when choosing a menu. By using the cookbook author’s ideas as well as his or her own preferences, the cook can design a perfect, unique meal for any situation.

This concept excited Owl. He thought back to the times that Bee or Ant or Singed-Tail had come to him for advice and had then commented on how much easier life would be if it came with instructions, just like a cookbook. At the time, he had wondered whether his friends were asking for a cookbook on how to live life, or for one simple recipe. He concluded that his friends were hoping for one single piece of advice that would guide them. But, as he had already explained to Bee after Bee’s disastrous real-estate experience with Ant, “One size does not fit all.”

Owl decided he would write a cookbook—one in which each “dish” would consist of a piece of sage wisdom. He would leave it up to the reader, however, to select the combination of dishes that fit the occasion.

Using Owl’s insight and a modified cookbook approach, we can design retrospectives in which individual exercises are like dishes that make up a meal. In this chapter, I provide a variety of exercises. You can browse through these exercises while you think about how well one or another or a combination of several might fit your particular retrospective. In all likelihood, you will pick a few exercises and leave the remainder for other times. Or, you may wish to use an exercise of your own design or one which you discovered someplace else. Select each component to complement and support the other selections, not to duplicate or compete with them. Each exercise must add something unique to the retrospective and contribute to the whole so that the complete retrospective experience (rather than a single exercise) is remembered as a positive professional experience.

Like a meal, your retrospective can have a number of courses, with each one designed to accomplish certain goals and to prepare the participants for the next course. I typically divide retrospectives into three courses, which I call the Readying, the Past, and the Future. These courses are described in the paragraphs below.

The Readying: The Readying course prepares community members for exploration of what went on in their project. It provides an initial period during which I can convey my strengths as facilitator to members of the community: I demonstrate my confidence in them, my competence, my attentiveness, my willingness to understand their problems, my flexibility, and my ability to maintain any needed control. In this Readying phase, I want members of the group to

• build a trust-based relationship with me

• become convinced that the process is likely to have a positive outcome

• adopt an attitude that allows discovery, openness, curiosity, enthusiasm, and risk-taking

• participate in the design of some activities in order to build ownership

• establish safety measures to ensure that the truth and people’s interpretations of events can be told without fear of retaliation

• design ground rules for behavior to be upheld throughout this retrospective

The Past: The purpose of this course is, literally, to dwell in the past, allowing individual team members to share their stories of the project and to help the group as a whole understand what really happened. Often, so much activity occurs during a project that no one person knows all that went on. During this part of the retrospective, members of the community can discover connections that they never before understood. They will have the opportunity to learn what the project really cost and how large it really was. They will be able to study the actual process, compare it with the intended process, and identify all problems. It is important to have everyone look at the damage that may have occurred to relationships and work to repair it. It is also important for members of the community to appreciate what was accomplished and to learn from each other through examination of their combined experiences. It’s a chance to marvel at how much was learned during the past project.

The Future: The purpose of the Future course is to focus on the next project. In this activity, the team explores ways to use what individuals have learned during the retrospective in order to improve the next effort. The whole community participates in the planning discussion, not just the managers. Planning at this point is not project planning, nor product planning, but process planning. For many of the team members, this will be the first time they will have consciously thought about the processes they use.

Wait, read that last sentence again. “Consciously thought about the processes” is important because it is at this point that the magic of a retrospective occurs. After carefully considering all details of the previous project, everyone on the team will be ready to try new methods. This is a teachable moment, when people are ready to make serious commitments to change their work practices. The buy-in is there—that is, the collective understanding of what might happen if they don’t change and the group’s understanding of why change is necessary. This is the perfect time for a team to identify its own process and to work toward improving it.

The real power of a retrospective is in your hands during this Future course. Select exercises that empower the community to grow, dream, and act in ways that improve its work practice. As facilitator, you’ll need to use subtlety at this point. Since the goal is to empower the community to do its own work better, then only gentle leadership is called for—you are giving the power back to the community. At the same time, you are still responsible for guiding the retrospective process. I find that my responsibility during this course involves listening first and then offering ideas to help people sell their vision.

Purpose: This exercise is designed to welcome the group, set the tone for the retrospective, and briefly cover procedural items such as agenda, break times, use of facilities, and so on.

When to use: Once—at the start of the retrospective.

Typical duration: 30 minutes. This activity needs to be short! Get through your introduction to the events scheduled for the retrospective quickly but without seeming to hurry.

Procedure:

Purpose: Sometimes, people think they are too busy to participate in a retrospective, believing that the three days could be used for something more important than talking about the past. This exercise is designed to awaken the curiosity of reluctant participants and thereby to help them want to participate.

When to use: Use occasionally, but do use as needed. Determine the need during your site visit before the retrospective. Listen for comments that indicate that people are skeptical that this is a good use of their time.

Typical duration: 30 minutes.

Background and theory: There are four reasons most commonly cited by people resisting a retrospective:

1. They fear the retrospective process might become a witch hunt.

2. They had a bad experience with a poorly run retrospective in the past.

3. They experienced no positive changes in the workplace as the result of a previous retrospective.

4. They feel overworked and pressured, tending to measure results by how much activity they have engaged in, not by what they’ve accomplished.

The first three reasons are addressed in other exercises and are relatively easy to handle in a well-run retrospective. The fourth is more difficult to dissuade people of and is addressed here.

Procedure:

Purpose: At the end of a project, most team members remember their very recent struggle to get the job done. They are so focused on the problems they encountered that they are not likely to step back and appreciate what they have accomplished. Even with the most seriously failed project, there are things about which a team can be proud. With a successful project, there are also things that can be improved upon.

In this exercise, I attempt to establish the idea that the project’s degree of success is not a relevant measure to use while people are trying to learn from their experiences. While not its goal, a benefit of this exercise is that it helps group members become comfortable with speaking openly—sharing what they think and having their opinions both heard and documented. They also learn to listen to other people’s ideas, possibly discovering that they have allies in the group who share their views.

When to use: If the project was completed, always include the “Define Success” Exercise. If the project was canceled, turn to the exercises in Chapter 8 for help.

Typical duration: 30 to 60 minutes, depending on how long presentation of the effort data requires.

Procedure: Using a group-discussion format, start the dialogue by asking, “Was this project a success?” As group members talk, record the reasons people give for believing it was or was not successful.

Somewhere in the middle of the exercise, present the effort data collected before the retrospective. Reflecting on this type of data will help the group focus on the big picture.

Often, the project was more successful than anyone realized. In the software industry, we have so many failed projects that the act of completing a software system and delivering it to a customer is an accomplishment in and of itself. If the particular project my retrospective is reviewing did come to completion, I cite industry data (from Capers Jones or Barry Boehm, for example) to suggest that the project was more successful than 85 percent of similar efforts. I might say, “If I were grading on a curve, I would give any project that gets completed at least a B+ without knowing the details.”

On the other hand, if the team insists on viewing the project as a failure, I let their truth stand. I then direct people’s attention toward learning from this failure so that they never have to experience such a negative event again.

Regardless of how the group as a whole views the success of the project, I generally close this exercise by offering a final definition of a successful project:

A successful project is one on which everybody says, “I wish we could do that over again—the very same way.”

With this concept fresh in people’s minds, I ask whether anyone thought the particular project met this definition. Usually, retrospective participants answer no. If that is the case, ask group members to think about what would have had to be different for them to answer yes. Then, ask them to take a few minutes to write down their thoughts.

This exercise will have been a success if participants have begun to give serious thought to what needs to be different, while considering what kind of project they would like to be a part of next time.

Background and theory: Effort data do not lie. When presented with effort data, people often discover that their impressions of the project have been wrong. Usually, far more work was accomplished than anyone realizes. Discovering this makes people curious about what other unexpected information might be learned during the retrospective.

The discussion of success establishes a precedent for talking openly about the project. The question posed is high-level and nonpersonal. Everyone has an opinion and can feel safe sharing it without the need to justify it. It becomes obvious that different opinions exist and all are to be tolerated. Also, the final definition of success sets a high standard for judging a project. It suggests that settling for less should be unacceptable. This idea may be novel enough to create even more group curiosity and enthusiasm.

Purpose: At the beginning of a retrospective, people may have many fears that will prevent them from talking openly and honestly about the project. This exercise is designed to create a retrospective atmosphere that is safe, one in which team members can feel comfortable talking about important issues.

When to use: Whenever the practice of holding a retrospective is new. For teams in which a retrospective is common practice, safety may not be an issue. Make no assumptions and do some investigation before holding this exercise, but it’s quite possible that safety was established in previous retrospectives, and that all the team members naturally expect this event will be safe. In these situations, the safety exercise can be skipped.

Typical duration: One to two hours.

Procedure:

My view on this changed when I facilitated a retrospective in which one vote remained a “1” no matter what we did to improve safety. We spent a great deal of time on several rounds of votes and safety-work sessions—to no avail. Everyone was pretty frustrated, so I called for a break and asked people to write confidential notes to me explaining their feelings. Here is the message I got from the holdout:

With that experience, I discovered that a lame-duck employee can cause a real problem in a retrospective if I expect everyone to feel safe. In this instance, I was fortunate because this individual was willing to share his secret.

Now if one or two people still feel unsafe after the second ballot, then I acknowledge that their worry is a reality for this group, and tell people that I hope that individual feelings of safety will change as the retrospective progresses. I point to the one or two low marks on the flip chart and say, “That’s a piece of information and we will see what comes up as we proceed. Just let it be for now.” Then I move on.

On the other hand, if most members of the community do not feel safe, then the whole retrospective needs to be redesigned to deal with that issue. There is no reason to go on. No other valid data will come from the retrospective.

During the evening of the second day, I reflected on how well the retrospective was going and suddenly realized that many of the ground rules had been broken! The violations were subtle and, during the first day and a half of the retrospective, I hadn’t noticed them. Faced with this realization, I imagined that a number of participants might be wondering why I had not commented on the ground-rule violations.

I decided to discuss the violations the next morning, and to begin to repair any damage that had been done by our disregarding the ground rules. I spent a restless night preparing to salvage what I could.

At the start of the third day, I reviewed the ground rules and asked the group to evaluate how well we were doing in maintaining safety and adhering to our rules. I took a third vote and was surprised by the results. The safety measure had gone up! By the last day, it seemed that the team understood that this was not a witch hunt, but a healthy review of the project. The small violations of ground rules were actually healthy signs that the team was comfortable with the retrospective.

Background and theory: I once asked retrospective participants to tell me what they were afraid of as we started the retrospective. They wrote anonymous notes on index cards and turned them in. Following are comments from individual participants:

• I’m shy in large group settings.

• I don’t negotiate well on the spot. I need time to process. I fear I’m the only one who feels this way.

• Someone might get angry with me for what I say or think.

• I fear I might inadvertently hurt someone’s feelings and damage future working relationships.

• If I express my opinions strongly, I may alienate myself from the team.

• My comments may affect the long-term impressions and perceptions people will have about me.

• The team will think I have a certain attitude.

• People may take offense at something I say. I especially worry when that other person is a manager.

• I fear the consequences for my family of me being fired because I spoke up.

• I fear the group will get sidetracked forever. We are very good at that.

• I fear being blamed for others’ problems—becoming a target.

• My fear is being misunderstood and doing more damage than good to the team.

• I’m afraid of being tagged a candidate for “culling” because of disagreement with the approach being taken by management. If I disagree with the way the team is being built/organized, will I be trusted?

• I fear feeling inept and becoming a source of pain for the team.

• I fear looking stupid and not being taken seriously.

• I fear exposing myself to people I don’t consider to be my friends.

• I fear long-term damage to my personal relationships, which may affect team effectiveness.

The fear people have of speaking the truth during a retrospective is real. However, while the feeling is justified, the actual danger may be far less than people imagine. The facilitator can help group members reduce their fear of speaking the truth by

• acknowledging that the fear is real

• letting people know that they are not alone in having this feeling

• addressing the specific fears

• asking each person to think of ways to establish a safe retrospective

Purpose: In this exercise, members of the community use the collection of artifacts from the project to recall events that occurred during the entire life of the project. This activity triggers the process that ultimately will tell the full story of the project. The exercise usually brings out the point that no one person knows everything that went on during the project, and shows people that a retrospective can be fun.

When to use: Once during each retrospective.

Typical duration: One to two hours. (The amount of time needed will depend on how many people attend the retrospective.)

Procedure: The “What Is a Retrospective?” handout discussed in Chapter 5 instructed participants to search for artifacts from their project, and described a contest in which prizes would be awarded to whoever brought the most artifacts, the most unusual artifact, and the most significant artifact. The steps for this exercise follow.

Holding up the notebook, she said, “This is the first project on which I’ve ever truly understood the whole system. It’s because of this project notebook. It is complete, consistent, coherent, and correct. My nomination for ‘most significant artifact’ is not really this notebook, but its author—Michelle, our technical writer!”

As the contract programmer finished speaking, the room erupted in applause. Although Michelle had been assigned to the project full-time to keep the project records as well as to develop the users’ manual, she had done much more for the project than perform just those two tasks. Her ability to find inconsistencies in the records and her tendency to keep asking questions until she understood the system caused the whole team to think, reflect, and rework.

When the votes came in, Michelle was named the team’s most significant artifact, possibly making this retrospective the first time in history that a group of archaeologists considered a living human being to be their most precious artifact! (It might also have been the first time in history that a technical writer was recognized for what he or she contributed to a project!)

Background and theory: At the end of a yearlong or multiyear project, most team members clearly remember only the last few months of work. They need to think about and review the entire project before the retrospective begins. In truth, asking people to think back over the life of their project results in very little thoughtful recollection. However, the search for artifacts provides structure, and encourages people to think without the facilitator ever mentioning review as a goal. The artifacts search provides an unusual and fun way to stimulate important memories.

Making participants aware—in advance—of each of the three awards has its own purpose:

• Knowledge of a prize for “most artifacts” causes people to review all the documents that exist and thereby encourages them to think about the entire project. It also ensures that the group will have the documents needed during the retrospective.

• Knowledge of the award for “most unusual artifact” causes people to think about the project in creative ways and encourages them to develop meaningful stories about the unusual artifacts they are considering.

• Awareness of the “most significant artifact” category causes people to ask themselves what was most important during the project.

The collection of artifacts provides a way to ease participants into review of the project. Presentation of the artifacts establishes an atmosphere of fun and celebration. As the artifacts are discussed, participants realize that many events occurred without their awareness. This realization arouses a curiosity that usually carries into subsequent exercises. Since curiosity is a key to learning, this is a valuable exercise.

An additional benefit lies in the fact that the community itself votes on the awards, demonstrating that the team (not the facilitator) is in the position of deciding what is and what is not important.

Knowles provides a theoretical basis for the “Artifacts Contest” Exercise in this study, which investigates the way adults learn.

Shaffer, Carolyn R., and Kristin Anundsen. Creating Community Anywhere. New York: Jeremy P. Thurcher/Perigee Books, The Putnam Publishing Group, 1993 (pp. 305–19).

In this book, the telling of stories and the sharing of artifacts builds a community through a common experience.

Sawyer, Ruth. The Way of the Storyteller. New York: Penguin Books, 1942.

The power of storytelling as a time-tested way of learning and sharing experiences.

Purpose: Building a time line allows each participant to add pieces to the collective story of the project. This exercise helps team members understand all that occurred during the project and enables them to build a disciplined framework for looking at the entire project in order to find the lessons that need to be learned.

When to use: Always.

Typical duration: Five to eight hours. (Spread this exercise over two days so that there is a night between for reflection.)

Procedure: This exercise is composed of two activities—the first is geared to building the time line, and the second, to mining the time line for gold.

As team members explained what they had accomplished during the three days, the VP became especially interested in the time line. He asked what would happen to it when we finished. Since we had already mined all the gold, I told him that we would probably throw it away. “No, please don’t. I need it!” he replied. He went on to explain that his field was not software but water-distribution engineering (the firm produced software to control large water-flow systems). He said he had never realized how complex a software project was. The retrospective time line made it clear.

“Next week, some of my people will be making a pitch to our Board of Directors, hoping to establish a software-engineering process group. Frankly, I haven’t been able to support them. I didn’t understand why it was important. I want this time line in the boardroom. It communicates instantly what goes on in our company. It’s real-life, not theory. This shows me that building professional software is much more complicated than what we were taught in my college courses. Now I finally understand why we need a software-process group.”

The time line was installed in the corporate boardroom and remained for nearly a year. I gather it was the stimulus for many useful discussions about the discipline of building software, using terms that describe the way engineers control water.

Purpose: On some projects, events cause unexpected changes in emotions. In this exercise, which is adapted from one I learned from my colleagues Jean McLendon and Eileen Strider, we explore the events that trigger emotional reactions. Our goal is to build better understanding.

When to use: I use this exercise on occasions when information submitted as pre-work indicates that there were numerous changes made during the project, and the people who made them (possibly the managers) didn’t appreciate the impact those changes would have on the emotional health of the community. A fellow facilitator, Esther Derby, always uses the seismograph as part of the “Develop a Time Line” Exercise. For her, the seismograph is the key guide during the “Mining the Time Line for Gold” activity.

There are several points at which you might ask the community to draw a seismograph: For example, you might suggest this exercise after the group has had time to reflect on the time line, or perhaps at the beginning of the next day, or even at the end of the “Mining the Time Line for Gold” activity. I’d like to be more precise, but it is a decision based in large part on intuition.

Typical duration: One to two hours.

Procedure: This exercise uses the developing time line, and can be executed concurrently with the “Develop a Time Line” Exercise.

Background and theory: It is hard to initiate a discussion of feelings in the workplace, but once started, comments seem to flow easily. This exercise is designed to slowly move the community into that discussion. The seismograph allows feelings to stay private but shows—by the color of marker pen—whether various members of each natural-affinity group experienced the same feelings.

The discussion of feelings shows team members that they are not alone. It also gives them a way to talk in terms of the group’s feelings while really discussing their own. As the discussion proceeds, individuals can shift from talking about the group’s emotions to talking about their own.

Course: The Past

Purpose: This exercise provides an opportunity to give recognition to everyone who deserves it. On every project, there are heroes. In fact, usually everyone on the team performs some heroic act, at one time or another, that helps get the software out the door. However, as a culture, we seem to have lost the inclination to give someone a “high five” or say “great job!” As a result, individuals who singly or collectively perform great feats of heroic behavior remain unappreciated.

When to use: Use this exercise to take a break from the “Develop a Time Line” Exercise, at the end of the day when everyone is tired, or when something happens in the retrospective that suggests the community could benefit from this exercise (for example, you could introduce the exercise when you notice a few people sneaking in compliments during one of the other exercises). I use this exercise in about half of the retrospectives I facilitate.

Typical duration: One hour.

Procedure: Start this exercise by asking people to contribute to a definition of the word “hero.” I usually look for a definition indicating some or all of the following characteristics:

A HERO IS... One who is endowed with great courage and strength, who is celebrated for bold exploits, and who is favored by the gods. ...One who is noted for feats of courage, especially one who has risked or sacrificed his or her life. ...One who is noted for special achievement in a particular field. ...One who has discovered and shared new knowledge, understanding, or inventions.

Ask whether there were any heroes on the project. You will usually get a few nods. Discuss the fact that the phrase “great job!” is rarely spoken in our business, and then explain the exercise by saying, “You see hero worship and recognition of achievement all the time in the sports world. The fact is, giving a compliment feels great, and doesn’t cost anything. On this project, everyone has had to do something significant to get the product out the door—and everyone needs to be acknowledged for that. I’d like this group to try the ‘Offer Appreciations’ Exercise. This is how it works: Someone who has an appreciation for another person will start off as ‘It.’ The person who is ‘It’ selects a hero, says the hero’s name, and gives the appreciation. The message must be in the form of ‘Tom, I appreciate you for...’”

Often, people will try to change the phrase into “I appreciate Tom for...” This use of the person’s name as the object of the verb does not have the same impact as does direct salutatory address—so, interrupt and help the speaker rephrase the message.

For some people, it is very hard to receive a compliment. Encourage them to just listen to the message. If they want to say “thank you,” that’s fine, but they need not say anything else.

Once the appreciation has been delivered, the receiver of the appreciation is now ‘It’ and can offer an appreciation to someone else. This goes on until everyone has been the receiver at least once.

End this exercise by observing that it really does feel good to receive “appreciations.” Giving one is a gift that costs nothing and means so much to the receiver. I tell the group that each of us is likely to think of more appreciations over the course of the retrospective as well as after our gathering. I encourage group members to share their appreciations as they come up. Then, I suggest that offering appreciations might be a good thing to add as an ongoing daily practice so that it becomes part of the group’s culture.

As described in Chapter 2, there are times when a manager wants to give an appreciation to everyone. If this happens, let it. It would be unfair and unwise to restrict a manager to an appreciation of only one person. Occasionally, I change the exercise to let people volunteer appreciations as they feel the need. The “It” game is used to get things started, but it can be adapted to fit the mood of the retrospective.

Theory and background: The fundamental goal of a retrospective is change. Virginia Satir studied how to help groups change and developed a six-phase model that includes making contact, validating, creating awareness, promoting acceptance, making changes, and reinforcing changes.

The second phase—validating a person’s self worth and willingness to consider the possibility of change—is built upon a foundation of offering a person honest expressions of appreciation. That is, appreciation for what the person has accomplished, what he or she has contributed or knows, or simply for who he or she is.

Loeschen provides an insightful discussion of Satir’s use of appreciation in this inspiring collection. My entire work on retrospective rituals could have been derived from the Satir Change Cycle described in Loeschen’s book.

Purpose: This exercise is designed to help people learn about their project by encouraging them to relax and let their minds wander while they enjoy a movie. The activity should be structured to offer entertainment that both provides parallels with the team’s project and that enables group members to view the project from a different perspective.

When to use: I save this exercise for residential retrospectives. It fits best on the evening of the first day. It usually follows the “Building the Time Line” activity.

Typical duration: Two and one-half hours to watch the movie, with an additional one to two hours for discussion on the following morning, depending on the community’s needs.

Procedure: Find a casual setting for community members to use that’s different from their regular workspace. A room with a large-screen TV/VCR set-up, comfortable couches, and over-stuffed chairs would be a good choice. Arrange to have snack food and soft drinks available.

Choose the movie that you feel most closely parallels the project you are facilitating. I almost always choose Flight of the Phoenix, featuring Jimmy Stewart and three co-stars. The plot of this movie, which revolves around the reassembling of a plane from scattered pieces of wreckage after a crash, provides an excellent analogy for most software projects.

Before showing the movie, instruct people to watch it while keeping in mind the context of their own project. At the end of the movie, ask everyone to consider questions such as the following for discussion the next day.

• How were events in this movie similar to those in your project? How were they different?

• What mistakes did the characters make that you avoided? How did your project avoid them?

• What did the movie characters do that you wish had been done on your project? How could their success have been experienced on your project?

• With whom in the movie did you most closely identify? Why?

By allowing people to “sleep” on these questions, you afford them the opportunity to process their ideas subconsciously. For many people, powerful insights come while they sleep.

To start the morning session on the next day, open the floor to a discussion of the questions. Use discussion of the next-to-last—which characters did people most identify with?—to set up the morning’s final activity before lunch. People usually mention four characters after viewing Flight of the Phoenix. For the final activity, ask the participants to move into groups, one for each of the identified characters. Direct all who identified with the pilot in Flight, for example, to move to one corner of the room, those who identified with the character of the navigator, to a second corner, and so on. Next, give all four groups the same assignment, designed to help them uncover preferences in their problem-solving styles. Choose the assignment according to what you learned from the pre-work handout. Here is an example:

Think about what mistake your character made with which you have some personal experience. Did others in your group make this same type of mistake? Discuss how you can prevent such mistakes from occurring during future projects. Once you have identified a pattern, select a representative to report back to the whole community on your group’s discussion and/or discovery.

Background and theory: In Flight of the Phoenix, the four main characters typify problem-solving behaviors that correspond to the four temperament types in Keirsey-Bates theory. That is, people have certain preferences in the way they work to solve problems. Fundamental to Keirsey-Bates theory is the premise that people must learn to appreciate both their own preferences and also the preferences of others who use different problem-solving approaches. Through understanding of these differences, teams can preserve their diversity while still honoring the preferences of others and taking advantage of their strengths. The following chart identifies the temperament type of each of the four characters in the movie and describes problem-solving styles.

If participants are not familiar with type identification, summarize the technique in your own words but make available reference copies of the six books listed in the following “References for Further Reading.” Do not insist on use of exact Keirsey-Bates terms but rather help people understand and verbalize their preferences. By asking people to select the character they most identify with, you help them articulate their temperament types and preferences. At this point in the exercise, you should be sure everyone in the group has a clear understanding of type differences. Guide type identification by asking questions such as the following:

• How did your character contribute to the team in a positive way?

• What weaknesses did your character have?

• What didn’t your character appreciate in each of the other characters?

• What should your character have done differently?

• How do your answers reveal opportunities to change, modify, or preserve the way you function at work?

Type preference theory is a powerful facilitator’s tool, and it is clearly presented in this excellent work. We revisit this material in conjunction with the exercises detailed in Chapter 9.

Myers, I.B. Gifts Differing. Palo Alto, Calif.: Consulting Psychologists Press, 1980.

This is the seminal work and should be read by all facilitators.

Weinberg, Gerald M. Quality Software Management, Volumes 1–4. New York: Dorset House Publishing, 1992–1997.

The Weinberg series provides much that is valuable on types and temperaments. See especially Appendix F in Volume 4, which gives a concise but clear summary.

Purpose: The purpose of this exercise is to help workers learn how to express their opinions honestly when they talk to management. In some environments, there is an “us versus them” attitude dividing managers from workers. Workers fear reprisal if they tell a manager what they think. Participants from such an environment are likely to begin the retrospective feeling oppressed and powerless. If you believe this to be the case from your review of the “Retrospective Pre-work Handout” or from initial interviews with project members prior to the start of the retrospective, then this exercise is a possibility.

When to use: I use this exercise infrequently and only when project members have tried to establish a safe retrospective environment, but have been unable to do so. The “Session Without Managers” Exercise is especially useful when the managers indicate that they want to hear what their workers have to say, but are frustrated because their people either don’t communicate or communicate ineffectively. By holding the “Session Without Managers” Exercise, you encourage healthy dialogue. (If I have determined during the retrospective-preparation stage that the managers are not interested in such a dialogue, I generally decline to hold the retrospective at all!)

Schedule this exercise to be given after the “Develop a Time Line” Exercise but before any of the exercises that belong to the Future course. While various issues will arise during the time-line activities, this exercise will help identify the few sensitive issues that are not explored during the “Mining the Time Line for Gold” activity.

Typical duration: Two to three hours, depending on the magnitude of the problem, the amount of instruction you need to provide, and how complex a message is developed during the exercise.

Background and theory: When workers are afraid to tell managers what they think despite the fact that managers want the feedback, there may be a variety of dynamics at work.

Reluctance to speak freely may result from a worker’s painful experiences with past managers. People who have picked up coping habits from previous work situations may carry those habits unknowingly into new relationships, even though the behavior is no longer needed.

A second dynamic may be a worker’s perception that the manager is playing the same role as an authority figure from his or her childhood: a parent, a teacher, or a school principal, for example. In this situation, the worker may use response tactics learned as a child. You might see such a person exhibit childlike behavior, such as becoming tongue-tied or uncharacteristically quiet; or the person may exhibit fast, shallow breathing or show a marked change in posture.

Conversely, responsibility for a lack of communication may lie with the manager who may have responded to feedback in the past in a way that discouraged future input. Perhaps the manager frequently interrupted the worker to point out that something was wrong, or perhaps the same manager failed to respond in any way to the worker’s input. Both scenarios can be fatal to open communication, but they do happen. Managers have a different perspective on the project and the company than workers have; they experience different pressures and difficulties, and they function in a world of budgets, office politics, and customer relations. Workers exist in a world of directives, schedules, and deadlines. Because both groups see events from such different viewpoints, either group may dismiss the other’s message as invalid.

Another dynamic barring effective communication may be a manager’s belief that he or she, as a leader, must have a solution to every problem. This expectation leads either to quick-fix solutions or to explanations of why things can’t change. Both of these reactions prevent people from really listening to other people’s ideas.

If any of these dynamics exist, they need to be addressed during this exercise. The key to opening channels for communication is helping the manager to understand that workers usually do want to be heard and that they don’t expect all problems to be fixed.

Procedure: Send the managers off to meet with each other to consider everything they have heard so far. Ask them to develop a statement summarizing their view of what happened on the project and specifying what they believe should be done differently next time. Remain with the group of non-managers, and work with them to develop a similar message to managers. If there are two facilitators, the second one should work with the managers. Do not divide the group of non-managers into two groups as you want a single message or statement to be developed.

As facilitator, I prefer to have one or more workers deliver the message to the managers; I agree to serve as spokesperson only as a last resort. My reason for staying away from this role is that I don’t have the context of experiences shared by the people on the project, and therefore cannot explain the message as well as they can. If no worker feels safe enough to deliver the message, I preview the content with the workers, asking them to provide verbal context and detailed explanation. Whoever seems most able to help me with the explanation usually becomes the person I will eventually ask to take over for me (again, my goal is to empower the workers).

A final note: The cartoon near the beginning of this exercise suggests an unpleasant situation. A workplace in which managers and workers are not in continuous effective dialogue is not a healthy one. The “Session Without Managers” Exercise provides a stepping-stone toward helping the community find a better way of working. Whenever this exercise has proven necessary, I follow it up with a worker-management communication-improvement activity in the Future course, usually as an item to be broached in the “Cross-Affinity Teams” Exercise.

Written for lay people, Satir’s work provides a good introduction to the topics of communication stances and rules. See especially Chapters 6 through 9.

Satir, Virginia. The Satir Model: Family Therapy and Beyond. Palo Alto, Calif.: Science and Behavior Books, 1991.

This book is intended for professionals in the field of therapy, but it can be quite enlightening to facilitators. Chapters 3 and 4 treat stances and congruence in greater detail than the topics are treated in The New Peoplemaking.

Seashore, Charles N., Edith Whitfield Seashore, and Gerald M. Weinberg. What Did You Say? The Art of Giving and Receiving Feedback. Columbia, Md.: Bingham House Books, 1991.

Now available directly from the authors—see www.geraldmweinberg.com for details—this compelling book explores the art of giving and receiving feedback, presenting the theory upon which the “Session Without Managers” Exercise is designed.

Purpose: During a project’s final days, everyone experiences a great deal of stress, and relationships between workers may become damaged. This exercise is designed to repair that damage by creating opportunities for people to play together. Playing time gives all participants a chance to release tension and to reflect on what they have discovered during the retrospective.

When to use: Daily, up to several times a day for residential retrospectives. It is effective to use evenings, after lunch, or whenever the community needs a break.

Typical duration: One hour or longer.

Procedure: This exercise is not one specific activity, but rather includes a variety of activities held as needed throughout the retrospective. The events range from unstructured, informal activities to well-organized games. I like to include both.

For unstructured activities, I give directions such as, “All of you have been indoors too long. Take your natural-affinity team outside and find something to do. Don’t talk about the project for at least thirty minutes. Let’s reconvene in an hour.”

Group members might go for a walk, take a bike ride, or simply sit on a park bench. They might explore the neighborhood, practice juggling, or just watch the clouds float by.

Structured activities usually involve playing games with rules, requiring people to interact with each other. Games afford opportunities for people to team up, either within natural-affinity groups or as non-affinity groups of people who don’t usually work together. Activities can range from pool, Ping-Pong, and poker, to touch football, tennis, or Pictionary. I ask members of the community to plan these structured, recreational activities because people tend to benefit more from recreational activities they’ve chosen than from activities assigned to them.

The process of working together to prepare food also provides an important bonding experience. People who plan, shop for, and cook out at a barbecue, for example, can become better teammates. Active participation in the preparation of a shared meal generally builds powerful team connections.

To motivate people’s participation in structured “play” activities, I bring to each retrospective an old trophy that I usually have been able to find at a flea market or in a consignment shop. To illustrate that this trophy is special, I tell some story that is too crazy to be believed, but which contributes to making the trophy prized by members of the community. Teams compete for the trophy in a variety of activities so that all individuals have the chance to demonstrate their particular skills. When I award the trophy, I explain, “This trophy is to become a continuous-challenge trophy, with the rules to be defined by you.” I give some examples of how people can continue to use the trophy on future projects, such as competing for the trophy only at the end of projects or only in sports that they have never played together before—the sillier the better.

Background and theory: When a team goes through difficult times on a project, no one enjoys the experience. Stress and tension are high, and people behave uncharacteristically. In such circumstances, it’s easy for team members to dislike the experience so much that they will decide to leave the team. However, a community that plays together will form special bonds. The relationships built around these play-filled times help individuals find new reserves of strength and patience to carry them through the hard times.

If you are facilitating a retrospective for a team whose members are already in the habit of playing, then this exercise provides a good opportunity for them to further strengthen their relationship. Through play, damage that occurred from end-of-project stress begins to repair itself. People see each other as individuals rather than just as barriers to progress or as reminders of problems.

Purpose: In the “Mining the Time Line for Gold” activity of the “Develop a Time Line” Exercise, issues were identified that required further discussion. In most cases, these issues will have emerged from a variety of viewpoints, usually representing the specific orientation or interest of the separate natural-affinity teams. In the time-line exercise, the community also identified topics that were puzzling. This “Cross-Affinity Teams” Exercise is used to further those discussions, by breaking the community into different subgroups. The goal is to identify better ways to direct the next project.

When to use: Always.

Typical duration: Five to six hours.

Procedure: This exercise uses two of the five flip charts created in the “Develop a Time Line” Exercise. Pick the charts labeled “What still puzzles us” and “What we need to discuss in greater detail.”

A final note: For some participants, this may be the first time they have been asked to prepare and present a verbal proposal to management, and they may not know the best way to proceed. Novice presenters often state their proposal in the form of “Here is what you need to do.” They fail to share the reasoning behind the proposal, behaving as if it were obvious. As facilitator, you may need to help cross-affinity teams articulate their ideas. One way I do this is, during the interim-report break, I ask the managers to describe what they consider to be a good proposal, saying, “What is the best way for these teams to sell an idea to you?” If possible, I also monitor how groups have organized their comments and give what guidance I can throughout the latter parts of Steps 4 and 5. Written directions often help a cross-affinity team get started. A sample of directions I hand out appears later in this section.

Background and theory: The “Cross-Affinity Teams” Exercise is designed to generate the energy and momentum needed to keep key lessons alive long after the retrospective has been concluded. Because the exercise brings a group of diverse people together to talk about what they want to change, the message to management must be viewed as a call to action. Through the discussion, the community commits to a new way of working, identifying the next steps and making plans to proceed. Expectations are established that next time will be different, and the group understands that it is not just management’s responsibility to facilitate the change. As a result, everyone who was involved in the discussion is motivated, and the team becomes empowered.

There is another reason why the exercise is important: The topics that end up on the “What we need to discuss in greater detail” flip chart are often politically loaded issues that spread across affinity groups. They are complex and not well understood, but the exercise fosters discussion among these disparate groups, and encourages people to see a bigger picture.

Before I could suggest any action, he e-mailed again. As it turned out, half-day retrospectives were the good news. The bad news came when, during a reorganization of the firm, directors in the new management decided to study the collection of retrospective reports. They thought the retrospectives would provide good insight into the group’s history, as well as suggest steps to take in the future.

However, the new managers soon discovered that the findings from each of the retrospectives for the past three years identified the same problems! Because no improvement occurred over time, they concluded that the retrospectives were ineffective. Their first action was to discontinue retrospectives.

In the company described by my True Story e-mail correspondent, canceling retrospectives was exactly the wrong thing to do. Retrospective reports were the best clue these managers had to understanding what was happening in their organization.

The retrospective can help initiate change, but keeping the energy alive is beyond the scope of a retrospective. It is up to the community to continue to work toward a better way of building software. This topic is discussed further in Chapter 10.

Purpose: Many times, as I approach the end of a retrospective, I sense that there is one last important topic that has not yet been addressed. The topic varies from group to group, but in all cases it is a topic that proves very difficult to discuss.

When to use: Once, during most retrospectives.

Typical duration: One to two hours.

I use the word “magic” for what happens during this exercise because how it happens is hard to explain. Here is what seems to occur late in the retrospective:

• People are tired and, as a result, most have lowered their guard and are less afraid of voicing their concerns.

• Each person has discovered something about the project that he or she had not realized before.

• People share a collective knowledge about the project, and know more about what went right and what went wrong than at any previous time.

• People who have been taking small risks and are close to saying what needs to be said see that the retrospective provides a safer setting to speak out than in their normal work environment. They feel more open to participating in candid discussions.

• Team members who have been hoping that a certain topic would be raised, now realize the retrospective is nearly at an end, and know that if they don’t bring up the issue themselves, it might not be discussed.

All the group needs now is an invitation from you, as the facilitator, to bring up that one last topic. If the topic can be raised successfully, participants usually find this exercise to be one of the most energizing events of a retrospective.

Procedure: This exercise is designed to initiate discussion of a difficult topic in a gentle, careful, and firm manner.

All preceding discussions have led up to this moment. As the facilitator, you will have seen and heard clues about topics that are important but which have not been discussed. The clues will have presented themselves during your interactions with the group, your early discussions with the managers, the pre-work dialogues, the one-on-one discussions you had before the review, and from comments made throughout the retrospective.

Following are typical comments that I have heard over the years:

• “There was too much work. We thought we were supposed to work long hours because everyone else did. The manager matched everyone else’s level because he wanted to be with us.”

• “Specifications changed continuously. These changes caused the developers to waste a great deal of effort. The community was working in circles, rushing through the specification stage so it would have time to repair the damage done because it had rushed through the specification stage!”

• “The next project might be much bigger than the last one. We feared that what worked before would not scale up.”

• “One person did all the organizational chores and tied together loose ends. Because the whole team depended on her, everyone felt vulnerable. If that critical person left, we feared the group would cease to produce software because the remaining staff didn’t really possess the knowledge to carry on her work. The critical person was also unhappy—she felt trapped and thought she had been passed over for promotion because she was too valuable in her current role.”

• “The manager misunderstood too many communication issues and then acted on his misperceptions. We spent a great deal of time putting out fires that the manager created.”

• “Senior engineers continually fought over minute technical issues that didn’t really matter to the project. We are tired of the turf battles and mental jousting.”

• “Too many managers were directing too few software developers. The result was a highly political multilevel management fight over scarce and worn-out developer resources.”

As facilitator, you need to invite that final discussion and then sit back and wait for people to begin speaking from their hearts. There are several ways to get this conversation started:

• Invite the group to speak out by saying, “We are coming to the close of this review. This is a good time to bring up anything that you were hoping we would get to but haven’t.”

• Reference what people have said by stating, “Throughout this retrospective, I’ve been hearing about how much effort you gave to make this system a reality. I know that three members of your team could not be here because of this. Take a few moments to reflect on what you personally sacrificed and write it down.”

• Speak the unspeakable. First, define the four freedoms as detailed in Chapter 9. Then, in a forthright manner, say, “We have spent days talking about everything except one really important issue. We have worked hard at avoiding the last thing that needs to be said. I want to talk about that.” Then let silence do its job. It may be awhile before someone gets the nerve to say something. Once the ice has been broken and the topic broached, group members have at least three options for responding: They can discuss the issue, they can discuss the reasons for not being able to discuss the issue, or they can bring up something completely irrelevant. You can work with the first two options. For the third, record what the person says, then ask, “And what else?”

• Adapt ideas from the “Art Gallery” Exercise described in Chapter 8. I usually use this exercise to help teams with failed projects begin to talk about their experience, but it is also useful to help get the last topic introduced. The “Art Gallery” Exercise lets team members use the right side of their brains to represent the project in pictorial form.

Once the last important issue has been brought up, I record the topic and ask others whether they see it the same way. I encourage more comments and then ask whether someone still sees the issue from a different perspective. If a person speaks in general terms, I ask for specific examples. If someone talks about one particular incident, I inquire, “How often did this happen?” I try to get a realistic perspective on the topic.

Next, I challenge group members to find common ground on the issue, asking them to determine what they all can agree on and what needs to be regarded simply as representing different viewpoints. I want to hear from each of the natural-affinity groups on this topic.

When the community begins to discuss a difficult issue, the facilitator needs to anticipate what will happen and to plan for it. To prepare, try the following:

• Watch the process and guide it. Provide opportunities for everyone to be heard. Demonstrate respect for everyone’s opinions as well as their privacy.

• Be willing to work with emotions as they come up. Moist eyes and even tears may appear during this exercise, but this is not a bad sign. Encourage the natural expression of emotions but stay focused on the topic.

To make the magic happen, keep in mind that every group needs something different. I have learned that I must be able to respond immediately and spontaneously to group behavior. I must put my own biases on hold and go with the discussion. As the facilitator, you will need to use your creativity, your experience, and your skills.

Purpose: This exercise ensures that the key findings of the retrospective don’t get filed and forgotten.

When to use: Late in the retrospective, usually as one of the final exercises. I use it in most retrospectives. I skip it if I know the team will keep the retrospective lessons alive.

Typical duration: One to two hours.

Background and theory: As stated earlier, the lessons learned from a project retrospective and the ideas of what to do differently next time can be easily forgotten. One way to preserve important details is the old-fashioned way—on paper! Paper can play a pivotal role in keeping issues at the fore as people implement change. Throughout modern history, leaflets, pamphlets, and newsletters have been fundamental to every significant change movement. Conversely, paper can be used to prevent change and to maintain the status quo when written rules and guidelines make positive action impossible. I recall many times during my days in academia when various departmental secretaries and even registrars at my university pulled out books on policy to show me—in black and white—why I couldn’t take certain classes, couldn’t get access to a computer, couldn’t be reimbursed, or wouldn’t receive course credit.

The “Change the Paper” Exercise is designed to keep the community’s memories and interest alive long after the retrospective has ended. The exercise causes team members to look at the role that paper plays in their workplace and helps them change that role, based on the lessons learned in the retrospective. Furthermore, while change is often resisted in a work-place, the medium of paper is rarely protected. Paper is easy to change, with little resistance ever offered.

Procedure: It is probable that as you prepare to facilitate your first few retrospectives, you will review numerous written documents. In addition to the documents, artifacts collected by the community will be made from paper or are information-based and were written on paper. It is a fact that paper plays a key role in most software projects. Some documents are produced and never used, while other documents are used extensively. By taking note of the documents that project members used, you will be helping them take an important step toward defining the software process.

Some of the most important pieces of paper won’t be found in a team’s files or notebooks but are those tacked to bulletin boards or taped to conference-room walls. Sometimes, they are even found outside the team’s work area. Look for them everywhere when you visit the team’s workplace.

For this exercise, I usually try one of three different options. Depending on available time and the level of the participants’ energy, I may even use more than one in a single retrospective. Following are the three I typically use:

At my suggestion, they created a poster entitled “Don’t Do Again.” Here is what was listed on it.

I then had them design a second poster entitled “Do Differently This Time.” For every item on the first poster, they needed to list at least one item on the second poster indicating what they should do instead.

Team members decided to place these posters in their conference room. Throughout their next project, they turned to the lists to see how they were doing. While working on any given task, if someone saw the project heading back to the old way, he or she could stop the activity and call for a discussion of the activities in the context of the two lists. By pointing out why it seemed the team was headed back to the “Don’t Do Again” list, and by checking the work against the “Do Differently This Time” list, the team could change its direction before it was too late.

Doing it “differently this time,” the team succeeded—it delivered the system version. But just as important, people on the team discovered that they could control the way they built software. They defined it, and they could change it. As a result of their achievement, they made development of a pair of posters a habit and a goal for each subsequent retrospective. By using retrospectives to define the improvements for the next project, the team could embrace change as a habit and an expectation.

. . . But the story does not end there—during a recent visit to the team’s site, I noticed that the first pair of posters was still on the wall. Alongside that first pair were several other pairs. I commented on the lists and one developer explained, “When new people join our team, they are told the history of our group, including what it was like to fail time after time. They are shown our posters, and we explain how we make sure we succeed. It’s a powerful and quick way to show how our group has agreed to work, and why. I tell them ‘Forget the corporate software development guidelines. These posters document our real software process.’”

Anchoring, a very powerful tool used in personal therapy settings to help set and reinforce an intended and desired change, is discussed in depth. By using the activity of reworking paper and, in particular, making posters, I’ve adapted the concept of anchoring to bring about change in the workplace.

Purpose: Every pageant needs to have an ending, and retrospectives are no different. This exercise brings a sense of completion to the work of the project.

Frequency of use: Once, at each retrospective’s end.

Typical duration: 10 to 30 minutes.

Procedure: The goal of this final exercise is to shift the community’s focus from the work of the retrospective to the real world. The procedure I use to do this generally is derived from some thing that happened during the retrospective. I watch for some theme or incident that can serve as a metaphor for the whole project and then use this topic or episode to create an ending exercise. If nothing suggests itself to you when you are facilitator, you can use the steps below.

Diana Larson is one of the best general facilitators I’ve ever met but she had never even heard of a software project retrospective before working with me as I drafted an early version of this book. I asked Diana to lead the retrospective for a project that I had participated in. The project was chartered to build an intranet-based, distributed, n-tier sales support application to be deployed globally. In addition to myself, the team consisted of fifteen people from five natural-affinity groups. One customer attended, along with a representative from a third-party software supplier. The project spanned a six-month period. Diana’s plan for the retrospective appears as the leftmost column in the tables. What actually occurred can be seen at the right. My observations in italics annotate both columns.

This retrospective, as planned, took two days only. We agreed to the two days because a number of personal schedule conflicts made a three-day event impossible. This book, however, recommends that all retrospectives take three days, plus or minus a half day if circumstances require the modification. So, was the shorter retrospective successful? My answer is, it was not. After attending the two-day event and comparing it to all the three-day reviews I’ve conducted, I’m convinced that a two-day event cannot adequately address all of the important issues.

Since then, I have determined not to yield to scheduling pressure. It is better to lead a three-day event and deal with a few people coming late or leaving early than to accommodate an event that cannot succeed.

In their article, the authors define a process and a community a bit different from the ones I write about. I urge you to read the article in order to appreciate another perspective on retrospectives—one in which the technical and managerial leaders are empowered, but possibly at the expense of big-picture learning for the entire community. I would expect their approach to become more attractive as community size increases to a size such as the one they describe of 150 people. The method I describe in Project Retrospectives has never been used on a community that large, and I doubt that it would succeed.

My goal in presenting the methods and exercises in this book is similar to Tom’s. Please feel free to adapt rather than adopt. In addition, avoid debates about whose approach is better. Instead, sample the Collier, DeMarco, and Fearey version of retrospectives as well as trying the methods discussed here. By experiencing both approaches and adding a bit of your own creativity, you will find a retrospective style that best fits your organization and uses wisdom from a number of sources.