An anatomy of a retrospective
If you have never experienced a well-run retrospective, then it is hard to imagine what it is like by simply reading a book. Nevertheless, this chapter tries to tie many of the discussions in this handbook into a single experience. It is based on one real-life retrospective, but spiced up with a few pieces from other retrospectives. I'm certain the participants would recognize themselves, but I hope I have changed enough of the trivia to protect their privacy.

This chapter shows how I use some of the exercises and tools discussed in this handbook. It doesn’t illustrate all the exercises, because in any single real-life retrospective, I don't use all the exercises. Also, I hope this chapter shows how I deviate from a preset plan as the occasion calls for it.


This example retrospective reviewed a project that produced complex software to help the genetic engineering community predict what would happen in a commercial gene-splicing environment.

The team was very strong in domain knowledge. There were seventeen genetic engineers who had learned programming skills on the fly to complete their Ph.D. dissertations. FORTRAN was their only programming language. The group also included four software developers who knew little about gene splicing but a great deal about developing UNIX-based applications. Three managers led the project. During the retrospective, one manager and two genetic engineers were out sick for reasons that could be traced back to gross overwork on the project.

This group was fresh from a research environment. They had never produced a software product before, and the project had several slipped schedules. Late in the game, major sub-sections were thrown away and rebuilt from scratch; several key researchers took early retirement at in-opportune times, and generally everyone worked too much throughout the summer and fall.

The project was critical to the business unit—the parent company wanted to see money-producing results since they were tired of funding research for its own sake.

The project, about 400,00 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 sales activities had so far produced only a few sales.


As part of my planning process, before holding the retrospective I interviewed each of the participants and came away with the following impressions:

• The managers were quite nervous about the retrospective. They saw it as a review of their ability to manage, and they believed that they had not yet learned how to be good managers.

• The software developers were worn out. They had worked too hard. They felt bad because they had missed the original schedule, but felt worse about the impact of the project on their personal lives.

• During the schedule slips, the managers had discovered that letting individuals "do their own thing" (as had been the norm in the research environment) resulted in system components that would not integrate. As a result, the head manager took on the role of systems architect and directed the genetic engineers to develop specific components. The genetic engineers 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 believed that the managers should have set the general direction and then trusted the developers to do the right thing.

• On the whole, I sensed very little pride in what had been accomplished. Everyone was focused on what had gone wrong, and they were not seeing what had gone well.

The retrospective was three days long and was held at an old hunting lodge. Before starting, I went through some pre-retrospective preparations with the group where I introduced the idea of a retrospective and made it clear that this was not to be a finger-pointing or blame session, but rather an opportunity to learn how to improve. I also explained that a retrospective was much like a architectural dig, and asked the participants to search for and bring meaningful artifacts from the project.

The Retrospective

Beginning (Morning, Day 1)

Define Success Exercise: At the last minute, the division head decided that he would attend the kick-off session. He wanted to tell this group how important he thought their work was. I also think he was curious to see what went on in a retrospective. I started to think how I could take advantage of the division head's presence. I decided to put more emphasis on understanding what had been accomplished.

After the division head's pep talk, I started asking the group whether they thought the project was a success. After hearing some half-hearted self-congratulations, I stopped the discussion. I presented the results of an effort data analysis I had one of their people to do. We looked at the total number of lines of code, the number of lines per defect, the number of lines produced per day, etc. I then contrasted what they had accomplished with software industry norms. I talked about the odds against a 400,000-line program even being delivered, based on the industry's history, and pointed out that their success in completing the project put them in the top few percent. From one point of view they were very successful. I think this stunned everyone, including the division head. I let this sink in.

Then I presented another definition of success. "At the end of a successful project, everybody says, ‘Gee, I wish we could do it again.’ Using this definition, was the project a success?" I got the group to admit that it was not this kind of project, and it would be great if we could figure out how to get there. I asked if anyone had been on such a project and a few people had. I asked them to talk about what it was like. This allowed us to explore how we could create such a project next time.

The division head left, and I went back to my original plan.

Create Safety Exercise: I stressed that the retrospective process is not for finding fault, but for learning how to do it better next time. I emphasized that participation in individual exercises is optional, and got everyone to agree to this basic rule, including the managers.

Since there were managers in the room, I wondered out loud if it would be safe to say what needed to be said. To find out, I had the group 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 asked the participants to move into "natural-affinity" groups—groups made up of people who have a close working relationship. The managers had their own affinity group. I charged each group with finding a private space in which to gather, and developing some ideas that would allow us to have a safe but still effective retrospective. Afterward, we returned and reported the ideas and figured out how to integrate each idea into the retrospective. An important request from this group was a "session without managers" where non-managers would meet privately. I would report the results of this session to the managers, who could then ask questions about the outcome of the session.

We also established these 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.

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

• There will be no jokes about other people in the room.

• These ground rules can be amended after any break.

Perhaps a few of these ground rules could use some explanation.

Talking coffee mug: A number of the women in the group found it difficult to participate. A few of the men would speak so quickly after someone else's comments that the women didn't get an opportunity to speak. When the women were speaking, sometimes they would pause—not because they were done speaking, but simply to take a breath. During this pause, someone else would seize the moment and take over the discussion.

One manager suggested that we design the exercises so that everyone must speak. The manager's intent was good—he wanted some of the quieter people to participate. But forcing them to say something violated my rule that "participation is optional." I explained that when people are forced to say something, they are likely to say what they think management wants to hear, not what they really feel.

After some discussion, we found an alternative. The manager volunteered his coffee mug as a talking tool. If someone had something to say and they were unable to get the group's attention, then they could pick up the mug. At that signal, everyone else was to stop and listen until the mug was put down or passed to another person.

No jokes about people in the retrospective: This ground rule is one I always establish for retrospectives. Sometimes humor is used to communicate endearment, and sometimes it is used for humiliation. As an outside facilitator, I can't tell the difference. Furthermore, there may be times when someone in the retrospective is feeling vulnerable and normal group humor might be taken as an insult. I have found it best to suspend all individual-based humor.

With the group guidelines set, it was time to take a second vote indicating how safe the group felt at this point. The ballots showed that everyone was comfortable enough (though a bit nervous) and we moved on to the next activity.

Artifacts Exercise: A week prior to the retrospective I asked the attendees to become high-tech archaeologists and search their office for important artifacts related to their project. Now during the retrospective I asked the archeologists to present and describe their artifacts, telling the story behind their treasure. We placed the artifacts on the floor in the middle of the room inside our circle of chairs. We studied what others had brought, and voted for the most significant artifact, the most unusual one, and the largest collection.

Many artifacts were documents. Someone had a collection of all the schedules, including the first one produced for the project. They laughed over how naive they had been. Another document described coding standards that many in the group had fought hard over, only to have no one use them. One important artifact was a place mat from a pizza house with a sketch of a new design for the database. When implemented, this revision had increased performance eight-fold.

One engineer brought in his can of Raid bug killer. It had appeared on his desk one day after a long night of systems integration and debugging, when he had found several serious bugs that had plagued the group for weeks. I asked him what this can of Raid meant to him. He explained that when he found the can, there was a yellow sticky note attached that just said, "Thanks." He didn’t know who had given it to him, but it meant a lot that a co-worker had appreciated his effort. Then someone commented, "Well, I didn't give you that can, but I want to say, ‘You did good.’ " A few people said, "Yeah," and "Right on." Suddenly the whole group applauded him. I'll remember the smile on his face for a long time.

As time went on, the artifacts lying on the floor grew into a remarkable collection. Everyone could sense that a great deal had been accomplished during the project.

As I read the group, I concluded that they were ready to discuss the project in a safe yet honest manner. We broke for lunch.

Middle (Afternoon, Day 1)

Time Line Exercise: In this exercise, I wanted each participant to add pieces to a collective story about the project. This activity helps the group understand everything that occurred during the project.

I passed out 5x8 cards to the natural-affinity groups. Each group had their own color of marker pen. Each group was to head off to their private spot to identify significant events or happenings from the project, listing one event per card. (The natural-affinity teams were used to reduce the number of duplicate cards.) This was an inclusive rather than a consensus activity. Any member of the group who thought an event was important could create a card for it.

It is always interesting to see how the different natural-affinity teams view the same event from different perspectives, and which events are not widely appreciated by all the groups.

While the groups worked on their cards, I put butcher paper along the wall, divided by seasons. When the groups were done with the cards we placed them on the butcher paper. The result was a whole story or timeline of the project, showing the significant events. Once this timeline was complete, everyone stood back and observed, noting how the cards told the story of the project from many different views. This particular team seemed to be more curious and awestruck that most.

Dinnertime was approaching and I knew we wouldn’t have enough time that day to process the timeline. I decided to alter my plan and do the processing on the following day. Instead I slipped in a different exercise to finish off the afternoon session.

Offer Appreciations Exercise: The group seemed impressed when they really looked at all that had gone into finishing their project. I thought it was a perfect time to discuss that feeling. I explained the next exercise and started it by offering an appreciation of my own.

I gave an appreciation to the person on the project who had developed and installed the configuration management and change control systems. This genetic engineer did not understand what configuration management was all about, but took it on faith that it was important. I believed that his care and work was key to the success of the project. A few other people agreed. I then asked him to give an appreciation.

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

We ended that session by deciding that we should head over the hills to a winery a few miles away. I had planned to run a Passive Analogy Exercise that night, but I decided that this team would get more out of wine tasting. So off we went, and spent the night comparing wines, wine labels, debating the importance of the color of a wine bottle and cork vs. plastic stoppers, and discussing the difficulties and joys of making your own wine.

Middle (Morning, Day 2)

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, only trying to get people to begin to think about the project again after a night of play. There were a few suggestions, but the one that I remember most was, "Well, it 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." There was silence after that comment as the group reflected on it.

Mining the Timeline for Gold Exercise: We moved into analyzing the timeline. Quarter by quarter, we looked at the events in the timeline to see what we could learn. We worked through the whole project, looking for what worked well, what lessons were learned, what could be done differently next time, and what topics needed more detailed study.

We broke for lunch. I scheduled a long lunch so everyone could get outside for a bit before we resumed. A few people went for a walk, while a group of us decided to play touch football on the tennis court. Sadly, I discovered how much my body had changed since I was a college student—I hurt for quite a few days.

Middle (Afternoon, Day 2)

Session without Managers Exercise: I asked the managers to meet together, consider what they had heard so far, and develop a message summarizing what they would like the genetic engineers and software developers to hear from the managers.

Likewise, I worked with the engineers and programmers to develop a message to managers. This is a very tricky activity to lead, because the people wanting a session without managers were feeling powerless, small and vulnerable. When people feel this way, they may develop a message containing anger, blame or more subtle negative feelings. I worked with the group to form a message that was honest but not accusatory.

As a single facilitator, I was vulnerable at this point because I could only work with one of the groups. Left on their own, some management teams might have developed an inappropriate message. Fortunately, this management group did not. If I had known earlier that we would break into two groups for this exercise, I would have arranged to have a colleague present to work with the management team. Instead, I previewed what the managers wrote before they presented it, and it was fine. If I had seen a problem with it, I would have arranged to delay their message until after dinner and worked with them through dinner to revise it.

After dinner, the managers and developers reunited into a single team, and I presented the developers' message to the managers, and let the managers respond. Then the managers gave their message. Things were getting pretty honest by this time.

I was struck by the similarity of the messages, although they were from different points of view. This doesn't always happen.

Middle (Evening, Day 2)

Repair Damage through Play Exercise: We finished the day by establishing a challenge among natural-affinity groups. That night we would have contests in pool, ping pong, air hockey and pinball. The winning group would get a trophy. Before the retrospective, I found an old trophy at Goodwill and had a new plate put on it, saying "1st Place - Retrospective Extra Curricular Activities." It looked funky, which was the effect I wanted.

The games went so well that I told everyone we would start an hour later in the morning. I think the group really needed that.

End (Morning, Day 3)

Cross-Affinity Teams Exercise: The next morning, we reviewed, organized and prioritized the topics that needed more detailed study from yesterday's Mining the Timeline for Gold exercise. These issues are often the politically loaded ones that involve 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. But now it was time to analyze the problems and propose solutions.

We prioritized the list, blending a few together, and divided the community up into cross-affinity teams (teams with members from each natural-affinity group). The list was divided among the cross-affinity teams, and the teams were asked to find a space of their own and study their assigned problem from many perspectives. They were to look for a number of possible solutions and to develop a proposal to be brought back to management. Managers were either available as consultants or could be invited to join a cross-affinity group.

After about two hours, the community reassembled and preliminary reports were given. After getting feedback from the larger group, the teams returned to their small-group work. Lunch time came, and I urged each cross-affinity group to eat together and go for a walk afterwards. Often major breakthroughs will happen during these walks.

End (Afternoon, Day 3)

In the afternoon, the finished proposals were made to management. The managers responded, and if they agreed with a proposal, I made sure that the community developed preliminary dates, milestones and owners for the tasks associated with the proposal. (Usually at this point in the retrospective, there is enough commitment among the group that people are quite willing to volunteer for the tasks.)

The proposals developed by this group included:

• 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;

• Understand 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 engineering is not below their dignity.

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

The community was now ready for one last exercise. Time was getting short, so I changed my plane reservation to assure ample time to complete the group's experience.

Making the Magic Happen Exercise: Every retrospective ending can be magical. The community has worked hard; people are a bit tired but feel comfortable discussing the project. They are now ready to talk about their most important issue, whatever that may be. All of the other discussions have been leading up to this moment. Although each group’s issue is unique, I’ve usually gotten clues about it throughout my interactions with the group—from my first discussions with the managers, from the pre-work, from the one-on-one discussions, from jokes throughout the retrospective—and so on.

My guess was that this team's issue was too much work. Everyone 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 anything less than 140% effort was not good enough.

I needed to make it okay to talk about the topic, and then sit back and wait for the group to start the discussion. To start things off, 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 overworked. Take a few moments to reflect on what you personally sacrificed and write it down on one of these cards. These messages will remain private—I won't collect them. I just think it would be good to have your thoughts written down."

After the group had written on their cards, I invited them to share what they wrote if they chose. I had seen enough risk-taking in this group that I sensed that this invitation would be enough to get things started.

One software developer started to talk about not being with his family on Sundays. Before the project, it had been a special time for them. He stopped mid-sentence as his voice cracked and his eyes began to tear up. I encouraged him. "Bob, stay with your feelings." He continued speaking from his heart.

Then a manager talked about being a cancer patient, and how he was concerned that the disease might be flaring up again because of the effort he had put on the project. A handful of others joined in, sharing what they had sacrificed.

At an opportune moment, I got the team to agree on one thing: "Never again!" The group declared this with feeling. I then suggested that each engineer place the card in a special place to remind him or her of this agreement. It was a good way to close the retrospective.

As a facilitator, was I prepared for this specific outcome? Not in the usual sense. The group went where they needed to go. My task was to help them get there, by:

A) watching the process and guiding it, providing opportunities for all to be heard, and respecting everyone’s opinions and privacy;

B) helping the group work under guidelines that yield healthy human interactions;

C) being willing to work with emotions as they came up.

To make the magic happen, every group needs something different. I have learned that my role is to be fully present and interact with the group, wherever they are going. I need to put my own biases on hold and flow with the discussion of the moment.

I’ve talked with some facilitators who haven’t yet learned to feel comfortable with the emotional energy that can be generated during a retrospective. They structure their retrospectives to avoid emotional situations. Sadly, when a retrospective is limited in this way, the magic doesn't happen, and the group may even feel that it was a waste of time. It is worth the effort for a facilitator to learn how to work with emotions, so the team can have that magic moment and know they’ve solved their most critical problem.

To give a good idea of what might happen in a retrospective, I’m sharing a portion of Chapter 2 from my book, “Project Retrospectives: A Handbook for Team Reviews.
Copyright © 2000 by Norman L. Kerth. Published by Dorset House Publishing, 353 West 12th Street, New York, NY 10014.

All rights reserved. No part of this web page may be reproduced, stored in a retrieval system or transmitted, in any form or by means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the publisher.

The four key questions | The retrospectives handbook | Biographical sketch | Home