This is a good overview of retrospective reviews. It is directed more at someone trying to bootstrap an agile process or fix a broken one. But it can also be useful for someone looking for fresh ingredients to add to a more established situation. The suggested team exercises sometimes come across as a bit more touchy-feely than I (or my team) are comfortable with. And the cheerful tone got a bit tiresome.

On the other hand, all that is exactly what I expected in a book like this. I was able to easily scan through it in an evening, culling the applicable ideas. Now it's just a matter of determining when I can add them into the mix. ( )

Techniques called “agile” comprise a more iterative approach to developing software. In many ways, it treats software as an open text instead of a fixed product. Agile development is used in most leading software shops around the world. This book treats a specific element of agile development – the retrospective. After each iteration or release, the team is gathered to discuss the last period of time and to seek improvement for the next time.

This approach is immensely helpful. It not only allows everyone to contribute to the group dynamics of software development, but it also provides a progressive framework so that knowledge is not lost. Software development is an especially quirky and peculiar area of life that is-like-but-is-not-like so many other disciplines (e.g., management, business, manufacturing, mathematics, arts, etc.). It is nice to have a book dedicated to this topic.

This book provides examples of exercises to perform with the team. For example, a timeline of the project might be charted to facilitate what happened in the last release. Or a matrix can be charted to share different insights about the last iteration. These exercises comprise the heart and the value of the book.

This book recommends performing an eight-hour retrospective after each release or after each iteration. I frankly could not imagine slowing down this frequently or for this long. Perhaps a one-hour focused retrospective (with one or two exercises) might be more helpful. Then again, I work with smaller teams that are continually having conversations such as these amongst themselves.

Overall, this book provides exercises that are helpful to draw out conversation among all those involved in software development. I’ll use it as a references as I lead conversations about software.

( )

Agile retrospectives are a great way to continuously improve your way of working. Getting actions out of a retrospective that are doable, and getting them done helps teams to learn and improve. This book helped me to develop and improve the way I do retrospectives, and to do agile retrospectives that are delivering value to the business.

This book can help you to improve the way you do retrospectives with Agile / Scrum. A lot of practical information on how to organize an run retrospectives, and to follow up on the actions. Must read if you want to continuously improve the way you develop software. ( )

If you're doing software development, you absolutely should read this book. If you're doing other sorts of projects, then you probably should, too. Portland's lucky to have Diana Larsen living right here.

Nice introduction to retrospecitves an the need for it. The first part of the book describes the process and steps of a retrospective and shows how to prepare one. Next the book continuous with activities (excercises) that you can do in the various stages of the retrospective. Usefulll, but it gives only a start. To do really effective ones, you will need a lot of experience that does not come forward well in this book. ( )

A good catalog of exercises for the different phases of a retrospective. As the title suggests, the focus is on smaller, more frequent retrospectives. If your retrospectives are becoming stale because you are always using the same format, this is the book to refer to. Also has a nice and quick introduction on how to prepare as a facilitator. ( )