Preface

Here is Edward Bear, coming downstairs now, bump, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it.

—A.A. Milne, Winnie-the-Pooh. London: Puffin Books, 1926.

So begins A.A. Milne’s children’s classic Winnie-the-Pooh. In these opening lines, Milne invites us to identify with the predicament of Edward Bear: The usual way of doing things—the routine—is not necessarily the best way and it is certainly not the only way. As I read Milne’s words, I marvel at the parallel between the world Milne describes and our own crazy world of software development. As software developers, we bump our heads in project after project, day after day. If we would only take a moment to stop and think of alternative ways to proceed, I’m sure we could find better ways to do our work.

Project Retrospectives: A Handbook for Team Reviews details creating a special ritual at the end of each project that lets us stop and reflect before proceeding with the next project. This ritual, called by many names—postmortem or postpartum, for example, or, my preference, retrospective—is important to our practice of software. In fact, I believe that it is the single most important step toward improving the software process! The reason for this is that a well-run retrospective can help members of a community understand the need for improvement, and motivate them to change how they go about their work. The community designs the changes, since it knows best how to identify, organize, and give priority to the problems to be solved. Owning the changes helps the community become the master of its software process. The process is the community’s—to use, to honor, to modify, or to discard. Most important, it is the community’s to review, again and again, after each project.

A retrospective can also help facilitate process improvement and changes that involve more than one team. The changes are often complex and cross group lines, requiring cooperation between multiple teams. A retrospective helps build this cooperation. The practice of holding retrospectives also serves as the cornerstone for efforts to improve software process. Given the rapid speed at which the software development field changes, we need to continually revise our work practices. Retrospectives assure that the software process adapts to advances in the field.

If a project fails, holding a retrospective provides a way for project members to learn from the failure and move beyond it. Its structure helps team members discuss how to improve, without eliciting accusations of blame or implications of shame. By avoiding a review of a failed project, the community loses a valuable opportunity to learn from its experience, possibly leaving the door open for the same kind of failure to happen again.

However, a retrospective is not just about improving software process. It also fosters learning, growth, and maturity in the participants. It provides an opportunity for project members to celebrate the successes and acknowledge the heroes in their community. The stories shared in a retrospective become part of a group’s tribal knowledge and tradition, as well as a source of long-term learning for the community. The experiences recalled during a retrospective help build a team with a common focus.

A retrospective can deliver on all these promises, but only if it is managed well. Learning to lead a retrospective isn’t exceptionally difficult, but how to do it best is not always an obvious process. It is my goal in Project Retrospectives to help you become a skilled retrospective facilitator, enabling you to provide the best possible experience for the software community you are leading as well as for yourself.

N.L.K.

October 2000
Portland, Oregon