By: Ester Derby and Diana Larsen,Raleigh, NC : Pragmatic Bookshelf , 2006 . 170+xi pages . Review by: Roman Pichler
When was the last time you attended a project post mortem, took away actionable improvement measures, and implemented them on your next project? I cannot remember my last time. The cause of traditional post mortems not being very effective lies in the term itself: The project is already dead, and most people have moved on to new projects that may have kicked off.
Retrospectives are similar to post mortems but take place while the project is still in progress. A retrospective means stepping away from day-to-day business, reflecting on how the project members collaborate, identifying issues and weaknesses, and creating actionable improvement measures. Retrospectives hence enable a regular inspect-and-adapt of the way people work. Morgan and Liker (2006, p. 211) believe that retrospectives and the learning and improving culture that accompanies them are one of Toyota's greatest strengths as a product development company.
Agile Retrospective is a book written by two seasoned retrospectives practitioners and provides an abundance of practical advice. The book concentrates on retrospectives that are carried out every few weeks, are focused and short, and allow a frequent inspect-and-adapt cycle. At the heart of the book is a process for running retrospectives and a collection of activities that help retrospective participants to reflect, learn, and improve.
The retrospective process introduced in the book has five parts. The first part is called “Set the Stage” and serves to create the right mindset and attitude to have an honest, open, and kind reflection that is free from finger pointing and blaming. “Gather Data,” the next stage, entails reviewing the last work period and creating a shared picture that takes into account the different perspectives and experiences of the participants. The following stage, “Generate Insights,” addresses the underlying causes for the key issues identified in the previous stage. “Decide What to Do,” the fourth stage, selects a small number of actionable improvement measures, and “Close the Retrospective” summarizes how the participants will follow up on the plans and identifies any improvement potential to make the next retrospective more effective and fun.
The activities, 30 in total, are grouped to align with the five stages. The activities range from well-known techniques such as “Five Whys,” which helps to perform a root cause analysis and is a standard technique used by Toyota (Liker, 2003), to lesser known ones like “Mad, Sad, Glad” that help to bring out people's views, feelings, and emotions.
In addition to the core parts of process and exercises, the book provides concrete advice on how to run retrospectives—thankfully without trying to write yet another book on facilitation but by nicely focusing on the key points. Additionally, the book describes how to conduct project-end retrospectives in comparison with the shorter, within-project ones. The book also contains a brief chapter on organizational change that helps to build a basic understanding and serves as a pointer to a complex subject.
Best of all, this book is short and spot-on. It takes probably no more than an hour to read through the key parts—something that can be accomplished even by very busy people. The advice given is hands on and actionable. The well-selected range of activities allows the retrospective facilitator to choose appropriate activities and to vary them over time. This introduces variety and creativity that help prevent retrospectives from going stale—particularly when they are performed frequently.
The book would benefit from stating the known sources of the activities, such as Toyota for the “Five Whys.” Additionally, a discussion of how to conduct retrospectives for multiteam projects would be desirable. Often projects consist of more than one team, and means to facilitate a large retrospective or roll-up the results of team-specific ones are required.
Interestingly, this book aims at software development, but it is general enough to be equally applicable to any type of product development. Should you be interested only in project-end retrospectives or in applications to larger teams or longer projects, Kerth (2004) is also worth consideration.
I highly recommend reading this book and putting its advice and activities into practice. I have used its process and some of its activities in recent retrospectives, and I have found the results to be very compelling. I would not want to miss the book as a guide and reference.
Released: October 2, 2013, 1:14 pm
| Updated: October 30, 2013, 12:14 pm