Chapter One. Introduction to Retrospectives

There once were three little pigs who, after surviving numerous harrowing encounters with the Big Bad Wolf, lived happily in their sturdy brick house at the edge of the forest. Having ousted the wolf, the pigs once again felt safe in their neighborhood. One day, the pigs decided to venture into the forest to visit their friend Owl. They liked Owl because he was very wise and could entertain them with all sorts of stories.

The story Owl told on this day entailed a group of humans and their repeated failed attempts to drain a swamp. The humans couldn’t complete the job because they kept running into alligators. After listening to the story, the pigs questioned why the humans needed to deal with the swamp in the first place. “Don’t these humans know,” the littlest pig asked Owl, “that swamps can be avoided altogether if they get Beaver and his crew to build dams to control water flow?”

“Don’t humans learn?” wondered the biggest of the three pigs. “Why don’t they learn to build dams?”

Owl replied, “It is a kind of insanity humans have. Humans, as a species, have hope. They hope that even if they do things that didn’t succeed before, that by doing them the same way twice, they will get different results.”

The pigs laughed with delight, and exclaimed, “Humans are the silliest creatures!”

Owl merely nodded, and then, having finished his story, he asked the pigs how their new project was going. “Great,” they replied. “Unlike those humans, we learned a valuable lesson from our last project.” The pigs told Owl how they had tried straw and twigs but had found brick to be the best building material they had ever used. They believed it would serve them well again for their current job—one on which they would build a real-life-tested structure to withstand even the strongest winds. In fact, the pigs explained, they would never use straw or branches to build anything again.

When the visit was over, Owl watched the pigs leave. He doubted that Noah, their client, would like the brick ark the pigs were building for him.

Engineering software means dealing with project alligators of all kinds while striving to remember what the true goal is. The three pigs wonder why one experience in the swamp is not enough to cause the humans to stop and question the premise for their activity—in other words, to ask why they are in the swamp in the first place.

Owl is wise, but the pigs do not share his wisdom—the learning that comes from experience. Without this type of learning, most creatures are in danger of reliving earlier experiences—landing back in the swamp time after time.

The three pigs believe that they have learned from their experience building wolf-proof homes, but have they acquired real wisdom? In a time of crisis, they select the first workable solution without careful analysis of its strengths and weaknesses or of its application to the present circumstances. Instead, they believe that what worked so well in one situation is the perfect technology to use in all their engineering efforts, whether they are building a house or an ark.

The pigs, like so many of us in the software engineering field, are missing the bigger picture. They are not adept at selecting the appropriate technology for the specific project at hand. Their amused reaction to the foolish behavior of the humans in Owl’s story gives credence to a fundamental observation about how all living creatures learn. I call this The Law of Wisdom Acquisition:

It is much easier to identify another’s foolishness than to recognize one’s own.

This law suggests that it is not natural for us to stop, reflect, and learn from our software projects. Of course, this is true! I am usually worn out at the end of one of my alligator-infested swamp-draining projects. I have hundreds of e-mail messages to deal with, a stack of journals I need to catch up on, and all sorts of other business issues that I have let slide. More importantly are the personal issues: I have to reconnect with my family and friends, start my exercise program again, and prepare for my postponed vacation. I might finally have time to go to the dentist, get my car serviced, buy some new clothes, and so on.

The act of reflecting on my just-finished project is not naturally a high priority. Yet it is the key to ensuring that my next project will have less water to drain and fewer alligators to manage.

The end of a software project is an ideal time for a ritual that helps people to reflect and be retrospective. The word “retrospective” itself means looking back on, contemplating, or directed to the past. Such a retrospective ritual should lead us to reflect on our project and allow us to look at our mistakes and learn from them.

But a retrospective ritual should not focus only on our mistakes—to do so misses so much! Every project has success stories that need to be heard and heroes that need to be honored. We learn things during a project, and we need to acknowledge what we learned or risk forgetting it. Therefore, the end of a project is also an excellent time to capture and analyze useful metrics—real numbers that can be used in the scheduling of future activities.

A retrospective ritual needs to include the entire community. Such a ritual can bring about a great deal of learning, and should not be limited to just a few individuals. It should involve everyone associated with the project. One person cannot know the whole story of the project; one individual’s reflection can only bring about small-picture learning. While one person might learn from specific experiences—like handling alligators with extra-long tails or sloshing water over a dike—there won’t be big-picture learning—such as how to keep alligators from entering the swamp, how to prevent the formation of a swamp in the first place, or how a certain way of sloshing water gets in the way of the people on the other side of the dike.

This big-picture wisdom comes from our ability to understand the relationship between an individual’s work and that of the entire team. We need to tell our piece and see how it helps make up the whole story. As a retrospective facilitator, I have seen whole-team reflection explain, discover, and teach so much. I believe that there is no better way to improve a team’s performance and quality.

Retrospective rituals are more than just a review of the past. They also provide a chance to look forward, to plot the next project, and to plan explicitly what will be approached differently next time.

A client of mine told me that throughout his career in the U.S. Army, he participated in a Post Engagement Redress (PER) after every major event in which he had been involved. By making a few calls to friends in the military, I learned more names for this ritual. The Army also uses the term After Action Review (AAR). The U.S. Navy uses Navy Lessons Learned (NLL), and sometimes even calls the review a Hot Wash Up. The U.S. Coast Guard has a great acronym: C-GULL (Coast Guard Uniform Lessons Learned).

While all these terms have their own appeal, I never grew comfortable with any of them. Then, Wayne and Eileen Strider, two fellow facilitators, suggested that we call what we do a retrospective. The word seemed appropriate; it didn’t carry any loaded meanings and it could be applied to projects without implication of success or failure. So far, this word has served me well.

In an ideal world, this kind of safety and trust would be a natural way of doing work. In the real world, members of the community may feel only a small degree of safety or trust. Each participant needs to choose the level of safety that is right for him or her. A method for expressing “unsafe” ideas during the retrospective needs to be established. To begin building safety and trust, the facilitator must communicate the prime directive for all retrospective rituals:

This directive, which I consider fundamental to my approach, reflects a mindset that needs to be part of everything that happens before, during, and after a retrospective ritual. As long as participants reflect this attitude, safety and trust can exist, and the retrospective can be a productive learning experience. If the prime directive is violated, the possibility of a successful retrospective ritual is significantly diminished and the retrospective will fail.

. . . most of the <retrospective rituals> that I have been involved with seem to have had the common flaw of turning into complaint sessions rather than learning sessions and, by virtue of that, the information wasn’t necessarily highly regarded (if not disregarded) and didn’t seem to be incorporated into subsequent projects.

Sue’s experience is not uncommon. Poorly run retrospectives can easily become gripe sessions, and when they do, very little can be learned.

Complaint energy is tricky to handle. The message in the complaint is worth listening to, but the packaging of the complaint can harm the learning process. Usually, the person issuing the complaint

• has only a partial understanding of the circumstances

• has experienced negative results from the project

• has developed a negative attitude through hindsight

• is feeling disempowered

The author of a complaint usually is not aware of the harm done by how he or she presents the message—such a person sees that there is something to be conveyed but doesn’t realize that the listener is put off by the complaint itself. Negative packaging is the first thing the recipient of the complaint sees, and this will probably prevent him or her from extracting the real message.

In the worst cases, when complaint energy is taken to an extreme, retrospective gatherings can become hostile. Individuals who are singled out for blame and fault during retrospectives often stop listening and can no longer learn. The following is an excerpt from an e-mail I received from one individual who was the victim of outright destructive hostility:

. . . the attacks started slowly. The first was small and tentative. I made the mistake of partially agreeing and partially defending myself. I was trying to learn and to acknowledge that I was not perfect. I was accused of being defensive and not listening. Funny, but I believe that I was the only one in the room who was really listening.

Anyway, by mid-day I was being attacked for almost everything, even if I had nothing to do with the situation. The side conversations at lunch and breaks were enough for me to close down and stop participating. Because of this experience and the following day-to-day interaction with my peers, I quit four months later.

After a decade, I still carry the trauma from that meeting. I’m not sure I would enter into another <retrospective ritual>.

I believe what happened was that people did not feel safe to look at their faults and, as a result, diverted the meeting away from themselves by attacking me.

My metaphor for that <retrospective> is one of twenty sharks feeding on a carcass.

Under such negative conditions, retrospectives cannot be expected to communicate any wisdom to participants other than “Don’t attend a retrospective!” One problem that was apparent from the above story was that no one felt safe enough to discuss faults.

A way to deal with complaints at a retrospective ritual is simply to outlaw them, but this is a bad idea. Complaints are based on valid experiences that need to be examined; they are the clues that there is an underlying problem awaiting discovery. In the design of a retrospective ritual, we need to use activities that will dissipate complaint energy and help us learn from complaints without letting their energy become destructive.

Becoming a facilitator for a software retrospective ritual involves much more than just helping people get together to talk about the project. What it does involve is the subject of this book, which is written for people who are committed to becoming retrospective facilitators. I expect that by reading this book, you will be introduced to many new concepts and ideas. One reading will adequately prepare you to plan small-scale retrospectives, but, with practice, you’ll learn how to become a master at facilitating retrospective rituals. Start with small projects, in which team members have worked well together. With time, try larger projects and consider teaming up with a more experienced facilitator to learn how to handle a retrospective for a community that has strong feelings about the project.

This book can be read as an overview of the topic by those who want to learn about retrospective rituals, or as a handbook for facilitators to use when planning and running a retrospective ritual. If you are reading this book to get an overview, you probably will want to look at the overview sections carefully (Chapters 2 and 3) and then browse through the more technical, exercise sections (especially those in Chapters 6 and 8). If you already are a facilitator, then all the techniques discussed in Chapters 3 through 10 will help you to plan and hold a retrospective. Since every project and every team is different from any other, every retrospective needs to be different as well. There is no one right way to lead a retrospective. You will need to take the ideas in this book and tailor them to your style of facilitating. Because one topic may lead to other reference material, a facilitator may decide to seek training outside the software-engineering field. This guidebook is meant to start the process by describing the steps needed to take a reader into the world of facilitation.

During my years as a facilitator, people have asked me to provide a set of step-by-step instructions on how to run a retrospective. I generally respond that I can’t draw a map because I’ve never been to the terrain that they are about to enter—remember, every project is different! However, I can provide instructions that can be used as guidelines. Readers can use this book as a guide to traversing unexplored terrain. Armed with this guide, readers can combine its wisdom with their own wits to survive the new wilderness of a retrospective ritual.