Retrospective versus White book. In conventional project management, it is called the white book. In agile, it is known as the retrospective. Both the retrospective and the white book serve the same purpose that is to learn from the past and improve the future. Though the objectives may be similar the manner and perhaps the efficacy are quite different.

The White Book and Eventually

In the case of the white book, we are either learning at the end of each phase of the project (more desirable) or we are learning at the end of the project. At the end of the project, we are unable to make use of any learning for that project. At the end of the phase, we will have performed significant execution while not taking a conscience and deliberate effort to improve. Additionally, what is recorded may not accurately reflect our total project experience. If we evaluate only at the phases, or at the end, we run the possibility of forgetting something or dwelling on the most traumatic aspects. We may lose some objectivity or clarity.
My experience with the white book is that somebody performs interviews and records this information into a “digital book”. The interviews do not happen (necessarily) with the entire team. That suggests a myopic perspective of the individual rather than the comprehensive view often required to understand the real and often complex situation. Even if there were measurements made during the project, these measurements were undoubtedly in the absences of the project execution. There is no knowing if those measurements identified at the beginning have a bearing on the resulting project. These may tell us nothing. For example, it would be analogous to measuring the floor molding to understand the size of the back splash on a sink.
The “book” (virtual that it is) is then put up. There is usually no metadata to facilitate sorting or recovery by future inquires.

The Retrospective and Immediacy

Since the retrospective happens at the end of a sprint and since each sprint is either two or four weeks, we see our memories are not so taxed to reconstruct what happened. Additionally, since the sprint team is simultaneously engaged in the review, any difficulty in reconstructing has the chance for resolution as our team is engaged in determining what actually happened. Further, since the retrospective happens at the end of the sprint, we can find our learning can more readily applied to the next sprint (assuming that we have more sprints to go).

When it comes to measurements, upon the critique of our present sprint (less than a month worth of work) if we desire.

The retrospective by process definition requires the entire team to participate. In fact, the lead of the retrospective may be a specific team member not like the conventional white book approaches which of often led by the project manager.  The retrospective addresses everything from human resources and team issues to process and product improvements.

Retrospective Graphic provided by Rick Edwards

Summary

Who says that conventional projects should wait to the end of the phase or project?  Perhaps it would benefit conventional project management to adopt a learning approach more like the retrospective. Why wait until the end of the project where we cannot improve the project outcome? Likewise, why wait until the end of a project phase to learn? Even those phases can be lengthy. Recovery of the information by posterity will still be difficult.

Check out some of the titles from The Pragmatic Bookshelf for additional information on the retrospective.