Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Other Sellers on Amazon
+ $3.99 shipping
+ $3.94 shipping
+ Free Shipping
Project Retrospectives: A Handbook for Team Reviews Paperback – February, 2001
|New from||Used from|
All Books, All the Time
Read author interviews, book reviews, editors picks, and more at the Amazon Book Review. Read it now
Frequently bought together
Customers who bought this item also bought
Top customer reviews
Project Retrospectives are review and improvement sessions which the project team does at the end of a project. A typical project retrospective takes a couple of days. During these days, there are a bunch of retrospective exercises which can be follows (and are described in the book). These exercises create a safe environment, help the project team remember the past and help them learn from it. An retrospective is not done properly if it doesn't also result in some improvement actions.
I've used Norm's exercises in my own retrospectives and they work exceptionally well. This book is therefore a treasure of practical advise. If you feel uncomfortable when reading the first description (as some exercises might), try not to discard the exercise, but try it out. Often you will learn and find that they work surprisingly good.
In the world of Agile Development, retrospectives have become an essential part of any agile method. These retrospectives are iteration retrospectives (or heartbeat retrospectives). They are shorter, but the ideas are the same. Much of Norm's exercises can also be used in that context.
As mentioned earlier, a must read for anyone serious in product development.
The first part of the book explains the need for ritual, how to tailor a retrospective to various situations, how to make a business case for having a retrospective, and how prepare for it. The case study Norm presents in the second chapter (Anatomy of a Retrospective) provides a holistic picture of the things to follow. The third and fourth chapters tell you how to tailor retrospectives to particular projects (Engineering a Retrospective: Making Choices) and how to talk groups who are interested in improving their processes into having a retrospective (Selling a Retrospective). These are important topics which determine if the people will be given the opportunity to learn from their own experience, and how to focus on the things that will make the retrospective effective. Chapter 5 (Preparing for a Retrospective) covers the groundwork required to have the facts and information for the retrospective, from initiating contact with the managers to arriving at the site. Finally, Chapter 6 discusses a wide array of exercises for the retrospective. Norm presents each exercise in a way that makes it easy to decide whether it is appropriate for a particular project. The pattern includes (among others): Purpose, When to use, Duration, Procedure, Background and theory, and References for further reading.
The second part of the book discusses postmortems, a special case of retrospectives. Postmortems correspond to failed projects. In Chapter 7 (Leading a Postmortem) Norm explains the differences between postmortems and retrospectives, and how to transform the failed-project experience into a learning opportunity. Chapter 8 (Postmortem Exercises) provides exercises designed to handle various circumstances typical of failed projects. In Chapter 9 (On Becoming a Skilled Retrospective Facilitator) Norm shares six lessons learned "through the school of hard knocks," and discusses several procedures that good facilitators should keep in their back pocket. Finally, Chapter 10 (After the Retrospective) explains what to do with the information that surfaces during the retrospective.
Norm has sprinkled the entire book with True Stories. They complement nicely the material and provide additional insight into how retrospectives work and what you should expect. I've also enjoyed the annotated bibliography at the end of each chapter; without Norm's summary the chances of my reading Sharon Loeschen's "The Magic of Satir" were slim. Finally, the book's illustrations are funny and to the point.
I've used Norm Kerth's Project Retrospectives in my Software Project Management class. My students have learned important lessons from it. I trust that once they become managers, they will keep the learning process going through wrapping up their projects with retrospectives.
The things I liked about the book: First, Project Retrospectives covers the topic completely in a very concise and readable way. You will find everything you need to know in this book in how to get started, how to be or find a facilitator, how to plan the retrospective, how to conduct the sessions - including a generous number of effective exercises, how to sell the concept of retrospectives to management and how to apply the lessons learned in an organization.
Second, I like the way that Kerth dealt openly and honestly with real world issues that surround project activities such as retrospectives that are often seen by management as "extras." Kerth treats this topic with integrity and basically advises that if you can't do the retrospective right, don't do it at all - or at least wait until you can do it right. I never had to try to separate theory from practice as I read the book - it was all practical.
Finally, I enjoyed the clear train of thought throughout the book, along with specific examples and case studies. I never had to wonder where Kerth was going with a thought.
It is time that we as software professionals make a ritual of reflecting on what we do and how effective we have been. In a profession where we try all too often to apply a single solution to many problems, the activity of project retrospectives can be a major force to improve the overall quality of projects. I highly recommend Project Retrospectives to project managers, consultants, QA analysts or anyone else wishing to be an agent of change in their organizations for higher software project quality.