Chapter 15. Looking Back, Looking Ahead[15]
Note
My friend Hank worked on a project that failed. The organization decided to try again. Hank suggested they conduct a retrospective to determine why the first project failed and feed that insight into the next attempt. "No," the project manager replied, "we don’t have time to hold a retrospective. We need to get started on the new project right away." One interpretation of this response is, "We need to get started immediately making the same mistakes again because it will take us so long to recover from them."
Retrospectives provide a structured opportunity to look back at the project, phase, or iteration your team just completed (Derby and Larsen 2006; Kerth 2001). You might identify practices that worked well that so you can repeat them. You can also learn what didn’t go well so you can make changes for next time. This might not seem like part of project initiation—indeed, it’s an important part of project close-out—but you can use the insights gained from a recent retrospective on the next project you undertake. Initiation is also an excellent time to plan the points during the project at which you intend to hold retrospectives, to make sure the time and team commitment are available.
A retrospective is a gathering of knowledge, lessons, metrics, and artifacts from a completed project or project phase, which helps the team learn how to do a better job on future projects. Metrics might include estimated and actual results for size, schedule, effort, cost, and quality, which are essential to improve your future estimates. You can archive key project artifacts—documents, plans, specifications—in your process assets library for other projects to study or to reuse. As Figure 15-1 illustrates, the outputs from the retrospective also feed into your organization’s lessons-learned collection, a list of potential risks, and future process improvement activities.
A retrospective provides closure, a way for the participants to share their observations away from the day-to-day work pressures. Even if the project was a colossal failure, the lessons you learn from evaluating it can produce something positive from the experience and point to useful improvement opportunities (May 1998).
This wrap-up activity goes by various names. Some people refer to it as a "postmortem" (even if the project was successful) or an "autopsy" (when it wasn’t). Other synonyms include "debriefing," "after-action report," "quality improvement review," and "postproject review." Consultant Norm Kerth, author of the definitive book on this topic, advocates "retrospective" as a neutral term that suggests a contemplative reflection on previous experience to gain practical wisdom (Kerth 2001).
You don’t need to wait until the project is over to learn from it. Consider holding a retrospective whenever you want to gather information about your project or evaluate how the work is going. Many projects pass through a series of development iterations, so you should gather lessons after each iteration to help with subsequent iterations (Derby and Larsen 2006). Reflecting on past experience is especially worthwhile anytime something went particularly well or particularly badly. It’s easy to forget what happened early in a project that lasts longer than a few months, so hold a short retrospective after reaching each major milestone on a long project. The healing effects of time and the exhilaration of recent success can ease the pain you suffered some time ago, but those painful memories hold the seeds of future improvements.
[15] This chapter was originally published (with Johanna Rothman) in Software Development, 2001, 9(2): 65–69. It is reprinted here, with modifications, with permission of CMP Media Inc.