Review By: Robin Goldsmith
05/11/2004The author has chosen the term “Project Retrospectives” as an alternative to the horrid “Postmortem.” He points out that the term I’ve used, “Post-Implementation Review,” wouldn’t apply to failed projects, which probably need review the most. Moreover, he treats retrospectives as a ritual that is important in itself for passing wisdom through the tribal (organizational) culture.

The ritual takes three days of facilitated group meetings, preferably at a location away from the office (he seems partial to rustic woodsy sites) to avoid interruptions; and he does acknowledge the difficulty of getting budget approval for what may seem excessive time and expense. Prior to the retreat, the facilitator sends the participants preparatory information and seeks feedback about key project factors to address. He encourages them to collect project “artifacts.” He also requests collection of data about the project’s time, effort, and output.

One of the big differences between this approach and the traditional approach is the author’s attention to “safety.” A retrospective is not about blame. It is assumed everyone did the best job they could with the time and information they had. He goes to great lengths to ensure that participants feel they can safely express their true beliefs and perceptions without having to fear peer ostracism or management retribution. This is not just a gripe session. It is so everyone can learn to improve for the next project. People are made aware of what they did accomplish and are challenged to identify those things that could have been done better. Managers generally do participate in these retrospectives, and it is the facilitator’s job to ensure the managers are there to learn and don’t impede or dictate the learning.

The participants form into “natural affinity groups,” i.e., people who work together. Managers are in a separate group. Each group identifies significant project events on index cards, which are then pasted on a big timeline on the wall. This helps people become aware of events that they didn’t know about. It also provides the basis for identifying things to repeat and things to improve. Since these exercises can be very draining, the author uses periodic recreational activities to provide renewal and team building. One such exercise is showing a movie and then discussing how each of the various roles approached solving problems in different ways.

The focus then moves from understanding what happened in the project to how to do better next time. Two categories get additional attention: “What still puzzles us” and “What we need to discuss in greater detail” (often the cultural/political issues). New groups are formed with members from each natural affinity group to address these issues. After these matters have been aired, the facilitator then asks the group to talk about the one thing they haven’t yet talked about. After almost three days together, they are now able to raise and deal with really difficult topics. This also is key to taking the steps to make improvements happen on the next project.

This book was not the belaboring of the obvious that I had feared. It was not like a Martha Stewart recipe I had seen for the “fresh raspberries” dessert course (“Wash berries. Arrange on plate.”). His use of what seemed to me to be overextended animal parables, wishy-washy phrases (e.g., “discover interesting things”), and psychology jargon, at first undermined my interest. But the author provided a thoughtful and insightful analysis of retrospectives that opened my eyes to a lot that I—and I believe many others in the software industry—have been missing.

The author claims his methods get people to implement the improvements everyone agrees would be valuable. While I don’t believe that everything he does is necessarily the best way, or as effective as it could be, as they say: “He’s got data.” That’s worth the price of admission. People charged with making change need to read about one way that actually seems to result in change.