Using Agile in less-than-perfect situations since Y2K
I am a fan of The Pragmatic Progammers series of books. They have mostly good material and I like their publishing methods. One of their books I have been meaning to read for a while is Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. I am happy to say that while it may not be the best of the Pragmatic series, it keeps up the good name. I would give it a seven out of ten.
Those of you who run in Agile circles should recognize those Author’s names. Esther wrote another Pragmatic book, Behind Closed Doors, with Johanna Rothman. I’ve read a number of her blog postings and articles over the years and generally like her style. She is also active at the Agile Conference, running the “Open Jam” stage/sessions. Diana was a director of the Agile Aliance from 2004-2006 and speaks at number of conferences.
The book follows a common pattern: a topic introduction, a set of “recipes”, and some wrap-up. In this case, the introduction covers the first three chapters. The first describes what a retrospective is, providing a framework for retrospectives by breaking them into five parts:
- Set the Stage
- Gather Data
- Generate Insights
- Decide What to Do
- Close the Retrospective
The second chapter describes the importance of fitting the retrospective to the organization, schedule, and other factors. The advice here is generally good. Using the same activities in every situation is at best not going to be as successful as using activities properly tailored to the context.
Chapter 3 gives some advice on how to effectively lead a retrospective. I found this reasonably informative, but some of the specifically recommended dialog felt a little like “pop psychology.” For example, “I’m hearing labels and ‘you’ language.” However, that is not to say that it isn’t good advice, or that I haven’t used something very like it before. And, of course, having lead a few retrospectives, some of this may have been more obvious to me than it would to someone without that experience.
The majority of the book’s content is in Chapters 4 through 8. These work much like a prix fixe menu for your retrospective. That is, they provide a set of activities from which to choose in building a retrospective with the parts described in the first chapter. Each chapter focuses on activities for one of those parts. If you have ever been in a retrospective, you will likely have seen at least a few of these. You may also have seen some that are not mentioned. What makes this valuable is not that it is unique or complete. It serves as a reference when trying to build a retrospective. I can easily see a team turning to this each iteration, especially when their last retrospective may have seemed stale or less productive.
Chapter 9 outlines some of the differences between retrospectives at iteration end compared to project or release retrospectives. These can be different in multiple ways (length of history being discussed, number of people involved) and the book provides some good insight here.
Chapter 10 is short, but provides some good advice and tips for how to get a team (and to a lesser extent an organization) to follow through on the decisions made as a result of the retrospective. After all, retrospection without adaptation is worse than wasteful.
Overall, I like the book. That said, if you are about to lead a retrospective for the first time, this book will not take the place of having been in a retrospective or having a good coach. This book can serve as good preparatory material to help build your confidence and give you options for when things take unexpected turns.
I would recommend this book more strongly to those involved in or leading retrospectives and finding them to be getting stale or losing effectiveness. The lists of activities provided in the middle chapters might just help.