Chapter Two. Anatomy of a Retrospective: A Case Study

If you have never participated in a successful retrospective, then it may be hard to imagine what one is like by simply reading a book. To help you visualize the process, I have put together a brief case study in the following pages to give you a sense of what can and should occur in a well-run retrospective. The chapter contains an overview of many of the topics and discussions that will be developed further in later chapters, tied here into a single story. The story is based on an actual retrospective, but I’ve spiced it up with bits and pieces from other retrospectives to make it a more comprehensive composite.

The chapter introduces a battery of exercises and tools that I use in retrospectives, most of which will be discussed more fully in later chapters of the book. You will see that the example does not make use of all of the possible exercises—for the simple reason that I never use all the exercises in any single real-life retrospective—but it does show how I deviate from an existing plan as the occasion calls for it.

Prior to working on this project, this group had been part of a research environment. The team had not produced a software product before. During the project, problems abounded: The project missed the schedule for several delivery dates; late in the project, major sections of code had to be thrown away and rebuilt from scratch; staff stability suffered as several key genetic engineers abandoned the project to take early retirement; and everyone who remained was grossly overworked throughout the final number of months.

The project was critical to the research unit’s future as company management wanted to change the unit from a research center to a revenue-generating product-development center, stating it was tired of funding research for research’s own sake.

The product, about 400,000 lines of code, eventually shipped about six months late. The system had defects in it, but they were not serious enough to prevent its acceptance in an emerging market. Customer response was positive, but few sales resulted.

• The managers were nervous about participating in the retrospective. They saw it as an evaluation of their ability to manage, and they feared it would show that they had not yet learned how to be good managers.

• The software developers were reluctant to participate because they were completely worn out and discouraged. They felt badly that they had missed the original schedule by six months, but they felt worse about the impact the project had on their personal lives.

• The managers were frustrated by the fact that letting individuals “do their own thing” during the schedule slips (as had been the norm in the research environment) had resulted in production of system components that would not integrate.

• The lead manager, who had taken on the role of systems architect and had directed the genetic engineers to develop specific components, was hostile to the genetic engineers who had resisted this change, which they viewed as a loss of scientific freedom.

• The software developers were angry at the managers for shifting into a micro-manage mode late in the development process. The developers felt they were being treated unprofessionally, and they believed that the managers should have set the general direction and then trusted the developers to do their job.

On the whole, I sensed that team members had very little pride in what had been accomplished. Everyone was focused on what had gone wrong, and could not see what had gone right. Before starting the three-day retrospective itself, I made it clear that the retrospective was not to be a finger-pointing or blaming session, but rather an opportunity for the participants to learn how to improve. I explained that a retrospective is much like an archaeological dig, and asked the participants to search for meaningful artifacts from the project to bring into the retrospective.

Beginning

My Goals:

• Help the community to get comfortable with me and with the idea of reviewing the project.

• Help participants create an environment in which they can articulate what is most important to them.

• Help participants realize that this project was a success because, although the odds were against them, they shipped a product.

My Approach:

• Select exercises appropriate to the specific situation. For example:

“Define Success” Exercise

“Create Safety” Exercise

“Artifacts Contest” Exercise

Middle

My Goals:

• Review the project for significant learnings.

• Repair damage to working relationships between team members.

• Recognize the costs of producing such a great volume of work.

My Approach:

• Select exercises appropriate to the middle of a retrospective. For example:

“Develop a Time Line” Exercise

“Mining the Time Line for Gold” Activity

“Passive Analogy” Exercise

“Repair Damage Through Play” Exercise

End

My Goals:

• Determine what long-term activities need to occur for the next project to be more successful.

• Identify what alternate group behaviors need to be accepted now that the group is to be less research-oriented and more product-oriented.

My Approach:

• Choose closing exercises. For example:

“Cross-Affinity Teams” Exercise

“Making the Magic Happen” Exercise

Because flexibility is important to the success of a retrospective, I do not attach a well-defined or rigid schedule to a retrospective plan. In this sample, allocating times would have been difficult since I didn’t know how the group dynamics would develop. I trusted my skills as a facilitator to make sure we would cover this plan in three days; otherwise, I would need to revise the plan based on the events that occurred. The following sections reflect how the events were handled. (Note: In this case study, I’ve used italics as a convention to highlight first use of the names of exercises so readers can locate them easily. The convention is not used elsewhere in the book.)

Right before the opening meeting, the division head decided that he would attend the kick-off session. He wanted to tell the group how important he thought its work was. I believe he was also curious to see what went on in a retrospective. After thinking about how I could take advantage of the division head’s presence, I decided to put more emphasis on understanding what had been accomplished, and elected the “Define Success” Exercise.

Once the division head had completed his pep talk, I asked group members whether they themselves thought the project was a success. Some members offered half-hearted self-congratulations, but they seemed unconvinced, and so I stopped the discussion.

To show team members how to quantify the success, I presented the results of an effort data analysis I had asked one of the team members to prepare prior to the start of the retrospective. We looked at the total number of lines of code, the number of lines per defect, the number of lines produced per day, and so on. I then contrasted what they had accomplished with software industry norms. I talked about the odds against a 400,000-line program ever being delivered, based on industry history, and pointed out that their success in completing the project put them in the top few percent of their field. From one point of view, they were very successful. Everyone seemed to be stunned by this fact, including the division head. I let this sink in.

Then I suggested another measure of success, saying, “At the end of a successful project, everybody says, ‘Gee, I wish we could do it again.’ Using this standard, was the project a success?” The group admitted that it had not been this kind of project, and stated that it would be great if we could figure out how to achieve this. I asked if anyone had ever been on such a project and a few people had, so I asked those individuals to talk about what their experience had been like. This discussion allowed us to explore how we could create such a project next time.

With people’s spirits significantly lifted, the division head departed, and I returned to my original plan. I repeated my statement that the retrospective process is not aimed at finding fault, but at learning how to do something better the next time.

I then introduced the “Create Safety” Exercise. I emphasized the fact that participation in individual exercises is optional. Everyone agreed to this basic rule, including the managers.

Since there were managers in the room, I wondered out loud whether people felt it would be safe to say what needed to be said. To find out, I had group members use secret ballots to show how safe they felt. Two people indicated that they did not feel very safe at this point in the session.

I then asked the participants to move into natural-affinity groups—groups made up of people who have a close working relationship—and directed the managers to form their own affinity group. The remaining team members divided into one group of genetic engineers and one group of software developers. Next, I charged each of the three natural-affinity groups with finding a private space in which to develop ideas that would increase the level of safety. After about half an hour, I called the groups back together and asked them each to report their ideas. This reporting session was followed by a discussion of how best to integrate each idea into the retrospective. One important request was for a session without managers, at which non-managers could meet privately. I agreed that I would report the results of the non-manager session to the managers, who could then ask questions about the outcome of the session.

We also established the following ground rules for group behavior:

• We will try not to interrupt.

• We will accept everyone’s opinion without judgment.

• We will talk from our own perspective, and not speak for anyone else.

• There will be no jokes made at the expense of anyone in the room.

Despite our ground rules, a number of individuals in the group found it difficult to participate. A few people would speak so quickly after someone else’s comments that others didn’t get an opportunity to speak. One manager suggested that we design the exercises so that everyone must speak. The manager’s intentions were good—he wanted to encourage quieter individuals to participate—but forcing people to speak violated the retrospective’s rule that participation is optional, a rule based on the premise that when people are forced to say something, they are likely to say what they think management wants to hear, rather than what they really believe.

After some discussion, we decided we needed some tool or object to signify a speaker’s right to speak without interruption. A manager volunteered his coffee mug as a speaking tool, and we agreed that if a person had something to say but was unable to get the group’s attention, he or she could pick up the mug. At that signal, everyone else was to stop talking and listen until the mug was either put down or passed to another person. We added the following ground rule to our list:

• If someone is holding the designated coffee mug, then only that person may speak.

The ground rule prohibiting people from making jokes about other people in the retrospective is one I always establish. Sometimes, humor can be used to communicate endearment, but sometimes it is used to humiliate. As a facilitator from outside the organization, I can’t always tell the difference. Furthermore, there may be times when someone in the retrospective is feeling vulnerable and even gentle kidding might be taken as an insult. I have found it best to suspend all individual-based humor.

Once the group guidelines had been set, it was time to survey group members again to determine how safe they now felt. The second set of ballots showed that everyone felt comfortable enough to move on to the next activity: the “Artifacts Contest” Exercise.

A week prior to the retrospective, I had asked prospective attendees to become high-tech archaeologists and search their offices for important artifacts related to the project. At the retrospective, as part of the “Search for Artifacts” Exercise, I asked people to present and describe their artifacts, telling the story behind their treasures. We placed the artifacts on the floor in the middle of a circle of chairs. We studied what each attendee had brought, discussed the importance of each selection, and then voted for the most significant artifact from the project and for the most unusual one. We also determined who had brought the largest collection.

Many of the artifacts from this particular project were documents. Someone even had a collection of all the schedules, including the first one prepared for the project. Everyone in the group laughed at how naive they all had been. Another document described coding standards that many in the group had fought to implement, only to have no one use. One important artifact was a place mat from a pizza parlor on which someone had sketched a new design for the database. When implemented, this revision had increased performance eightfold.

One engineer brought in a can of Raid bug killer. The can had appeared on his desk the day after he spent the night on systems integration and debugging and had uncovered several serious bugs that had plagued the group for weeks. I asked him what this can of insecticide meant to him. He explained that when he found the can, there had been a note attached to it that just read, “Thanks.” He didn’t know who had given the can and note to him, but it meant a lot that a co-worker had appreciated his effort. After he finished his explanation, someone commented, “Well, I didn’t give you that can, but I do want to say, you did good.” Others in the group agreed, and then suddenly, the whole group applauded him. I’ll remember the smile on his face for a long time.

As time passed, the pile of artifacts grew into a remarkable collection. From the discussion of the artifacts, everyone could understand how much really had been accomplished during the project.

As I looked around the group, I concluded that we had achieved the goals for the beginning of the retrospective and were now ready to move on to the middle of the plan. As it was nearly noon, we broke for lunch.

Middle (Afternoon, Day 1)

When we reconvened, I initiated the “Develop a Time Line” Exercise. In this exercise, each participant adds details to a story recounting the project, contributing pieces to a collective history. This activity is designed to help group members remember everything that occurred during the project.

To start things off, I passed out five- by eight-inch index cards to the three natural-affinity groups, and gave each group its own color of marker pen. I then sent each group off to a private space where group members could identify significant project events or happenings, listing one event per card. (By assembling people in natural-affinity teams, I expected to reduce the number of duplicated cards.) I instructed the groups to make this an inclusive, rather than consensus, activity. That is, any member of the group who thought an event was important could create a card for it. (I always find it interesting to see how different natural-affinity teams view the same event from different perspectives, and to see which events are not widely appreciated by all the groups.)

While the groups worked on their cards, I taped butcher’s paper to the wall, marking it according to seasons. When the groups were done with the cards, we taped them to the butcher’s paper, positioning each card in the section marked for the season in which the event took place. The result was a time line of the whole project that showed what project members viewed as the significant events. Once this card-taping activity was completed, everyone stood back and observed, noting how the cards told the story of the project from many different perspectives.

With dinner-time approaching, I knew we wouldn’t have enough time to process the time line, so I altered my original plan and rescheduled time-line processing for the following day. In its stead, I selected a different exercise to finish the afternoon session: the “Offer Appreciations” Exercise.

After observing that people in the group had seemed genuinely impressed when they looked closely at all that had gone into finishing their project, I told the group that the remaining time was a good opportunity to discuss that feeling. I explained the “Offer Appreciations” Exercise and started it off by voicing an appreciation of my own.

First, I complimented the genetic engineer who had developed and installed the project’s configuration-management and change-control systems. This particular engineer did not have any specific training in the area of configuration management, but had taken it on faith that it was important. I stated that his effort was one key to the project’s success. I then asked him to offer appreciation for someone else’s work.

Appreciations continued to be traded until one of the managers took his turn, and completely took over. Feeling frustrated because I was letting each person offer only one appreciation at a time, he said he needed more than one turn. He then proceeded to give everyone in the group a sincere and significant appreciation. For some members of the group, this was the first time they realized that this manager even knew what they had done. I could see that team members were beginning to feel better about each other and to pull closer together as more appreciations were offered.

Although I had planned to run a “Passive Analogy” Exercise that night, I sensed that the team would get more out of doing something recreational. We ended the session by deciding that we should head over the hills to a winery a few miles away. So, off we went, spending the evening comparing wines and wine labels, debating the importance of the color of a wine bottle and of cork versus plastic stoppers, and discussing the difficulties and joys of making wine.

I started the second day by asking, “How did last night’s activity resemble the project we are reviewing? How was it different?”

I wasn’t looking for a specific answer, but wanted people to think about their interaction on the project in contrast to how they had functioned in a purely recreational setting. Of the many interesting observations, the one that seemed most insightful came from one of the genetic engineers: “Well, last night’s outing was like what we used to do all the time when we were a research organization. But then we got too serious about making a product and we lost sight of how to have fun.” Silence followed that comment as the group reflected on it. In order to allow people more time to consider the comment’s implications, we agreed to table further discussion in favor of moving on to analyzing the time line in the “Mining the Time Line for Gold” activity—part of the “Develop a Time Line” Exercise.

Taking the time line season by season, we looked at events to see what we could learn. During the remainder of the morning, we worked through the whole project, identifying what was effective, what lessons were learned, what could be done differently next time, and what topics needed more detailed study.

When we broke for lunch, I allotted enough time so that everyone could eat and then get outside for some recreation before we resumed with the next session. A few people went for a walk, others talked as they tossed Frisbees, and another group played touch football on the tennis court. Although I didn’t explain this to the group, by interspersing work sessions with recreation, I hoped to keep energy levels high.

Middle (Afternoon, Day 2)

For the post-lunch time slot, I asked the managers to go off to first discuss what they had heard so far and then to develop a brief message summarizing what they would like the genetic engineers and software developers to think about. With the managers gone, I began the “Session Without Managers” Exercise, working with the team of engineers and programmers to develop a message for their managers.

Because the people wanting a session without managers may be feeling powerless, small, and vulnerable, this exercise is tricky to lead. When people feel this way, they may develop an angry, blameful, or more subtly negative message. I helped the group to form a message that was honest without being accusatory.

As the lone facilitator on this retrospective, I could only interact with one of the groups at any given time. Left to their own devices, some management teams develop inappropriate messages, but fortunately, this particular management group did not. If I had known in advance that we would need to break into one group of managers and one of non-managers, I would have arranged to have a colleague work with the management team. Instead, I read what the managers wrote before they presented it to the other participants and saw that it was fine. (If I had believed there to be a problem, I would have arranged to delay their message until after dinner so that I could work with them through dinner to redirect or rephrase the message.)

After dinner, the managers and developers reunited into a single team. I presented the developers’ message to the managers, giving the managers a chance to respond before they delivered their own message. Discussions were getting pretty honest by this time.

I was struck by the similarity of the messages, despite their having been prepared from different points of view. This does not always happen.

Middle (Evening, Day 2)

I ended the day with the “Repair Damage Through Play” Exercise by staging a friendly competition between natural-affinity groups in games of pool, Ping Pong, air hockey, and pinball. I explained that the group to win the most points would get a trophy. I had brought with me an old trophy I had found at Goodwill that I’d had inscribed with “1st Place—Retrospective Extracurricular Activities.” The trophy looked hokey, which was the effect I wanted.

When we reconvened the next morning, we reviewed, organized, and listed in order of priority the topics that needed more detailed study from the previous day’s “Mining the Time Line for Gold” activity. These topics often turn out to be politically loaded, involving intense interactions between natural-affinity groups. On the previous day, when the goal was to view the whole project, I chose not to address these difficult issues, reserving the final day as the right time to analyze problems and propose solutions.

Working as one large group, we reviewed the ordered list, and blended and merged some items. Next, to begin the “Cross-Affinity Teams” Exercise, I split the group of non-managers into teams composed of a mixture of members from each natural-affinity group. I then divided the full list of problems evenly among what were now cross-affinity teams (teams made up of people who did not generally work together), and sent the teams off to study their assigned problems from multiple perspectives. Teams were instructed to take two hours to look for possible solutions and to develop a proposal for management to review. Managers made themselves available either as consultants or, if invited, as members of a cross-affinity team.

After approximately two hours, I reassembled the community and asked individual teams to deliver their preliminary reports to management. Armed with feedback from the larger group, the teams then returned to their small cross-affinity groups, working until the lunch break to prepare final reports for management. As a bonding strategy, I urged each cross-affinity group to eat together and then to go for a walk. By encouraging such close group interaction and by keeping members together for the walk, I hoped to foster the kind of major breakthroughs in problem-solving that should occur during a retrospective’s third day.

End (Afternoon, Day 3)

After lunch, the groups presented finished proposals to the managers for their response and approval. Whenever managers support the actions recommended in a proposal, I make sure that the community as a whole develops preliminary dates and milestones, and identifies people to perform the tasks associated with the proposal. (Usually at this point in the retrospective, there is enough commitment within the group that people are willing to volunteer for the tasks.)

The recommendations proposed by this group included the following.

• Reduce micro-management by having teams accept responsibility for assuring that their piece fits into the project architecture.

• Learn more about analyzing and designing systems and software before starting the coding phase of a project.

• Recognize that the group works in two modes: research and engineering. Learn to distinguish between the two modes, know when each is appropriate, and accept that the engineering model is on par with, not inferior to, research.

This exercise was hard work, but once accomplished, it provided a vision for the group’s future that would be better than the past.

The community was now ready for one last exercise: the “Making the Magic Happen” Exercise. Holding this exercise at the end of the retrospective’s three or four days is critical. A retrospective’s ending can be magical. The community has worked hard; people are tired but feel comfortable discussing the project. Project members are now ready to talk about their most important issue, whatever it may be. All of the other discussions have been leading up to this moment.

Although each group’s issue is unique, I’ve usually received clues about it throughout my interactions with the group—from my first discussions with the managers, from the pre-work I’ve assigned to members, from the one-on-one discussions, from casual conversations, and so on.

My guess was that this team’s primary issue was that it had had too much work. Team members all had thought they were supposed to work long hours because everyone else did. The managers matched the engineers’ hours because “they wanted to be with them.” The engineers, in turn, saw their managers at work all the time and thought that any effort less than 140 percent was not good enough.

My strategy was clear to me: I needed to make it acceptable for people to discuss the topic, and then I would sit back and wait for the group to open up. To trigger the discussion for this particular group, I said, “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 were not able to be here because they were sick—probably because they were overworked. Take a few moments to reflect on what you personally sacrificed and note it on one of these index cards. These messages will remain private—I won’t collect them. I just think it would be helpful for you to see your sacrifices written down.”

After group members had listed their sacrifices on the cards, I invited people to share what they had written—if they chose to. I had seen enough risk-taking in this group to believe that my invitation would be sufficient to get things rolling.

The flood gates opened: One software developer talked about not being with his family on Sundays. Before the project, he reported, Sundays had been a special time. He stopped mid-sentence as his voice cracked and his eyes filled with tears. I encouraged him to stay with his feelings, and he continued to speak from his heart. Next, a manager talked about having been a cancer patient, and expressed his concern that the disease might recur because of the effort he had put into the project. Cautiously, others joined in, sharing what they had sacrificed. Throughout the session, support from the group was expressed for each person who spoke.

As the retrospective drew to a close, I got the team to agree on one thing: “Never again!” the group declared with feeling. I then suggested that each engineer, manager, and software developer place the index card in a special place as a reminder of this agreement. The suggestion was a good way to close the retrospective.

As a facilitator, was I prepared for the specific outcome? Yes, I was prepared, but not in the usual sense. A retrospective group goes where its members need to go. The facilitator’s task is to help them get there, by

• watching the process and guiding it

• providing opportunities for all to be heard

• respecting everyone’s opinions and privacy

• helping the group identify guidelines that yield healthy interactions

• being willing to work with emotions as they come up

Every group needs something different to make the magic happen. I have learned that my role as facilitator is to be fully present and to interact with the group, regardless of whatever concerns members raise. As a facilitator, I need to shed my personal preferences and be open to whatever discussion arises.

Some facilitators haven’t learned to feel comfortable handling the emotional energy that can be generated during a retrospective, so they structure their retrospectives to avoid emotional situations. It has been my experience that when a retrospective is limited in this way, it is more difficult for the magic to happen, and the group may even feel that the retrospective has been a waste of time. It is worth the effort for a facilitator to learn how to work with emotions, so the team can have its magic moment and know that team members solved their most critical professional problem.

• build trust within the community

• lead the exploration of difficult issues in a humane, caring, and effective manner

• ensure that managers participate, contribute, and learn, rather than dominate

• help the group to understand what its real issues are

• help team members find improved ways of working together

Because a retrospective facilitator in the software engineering field needs a broad range of skills, knowledge, and ability, it is advantageous if he or she is also a disciplined practitioner of software engineering and project management methods. Such a facilitator must know how to guide a group of people and how to manage conflict. He or she must be sensitive to emotion and know how to handle it, must be able to recognize team dynamics and how they affect the community, and must be ready to use all available tools and skills to help the community become more effective.