With detailed scenarios, imaginative illustrations, and step -- by-step ins tructions, consultant and speaker Norman L. Kerth guides readers through productive, empowering retrospectives of project performance.Whether your shop calls them postmortems or postpartums or something else, project retrospectives offer organizations a formal method for preserving the valuable lessons learned from the successes and failures of every project. These lessons and the changes identified by the community will foster stronger teams and savings on subsequent efforts.
For a retrospective to be effective and successful, though, it needs to be safe. Kerth shows facilitators and participants how to defeat the fear of retribution and establish an air of mutual trust. One tool is Kerth's Prime Directive:
Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.
Applying years of experience as a project retrospective facilitator for software organizations, Kerth reveals his secrets for managing the sensitive, often emotionally charged issues that arise as teams relive and learn from each project.
Don't move on to your next project without consulting and using this readable, practical handbook. Each member of your team will be better prepared for the next deadline.
This is the first book that I have read on retrospectives, after having seen Norm Kerth on the SM/ASM conference in 2001 presenting about retrospectives.
It's a classic, even if you do agile retrospectives, as it describes the basic concepts and ideas behind retrospectives. A must read for anybody of is working agile, and want to continuously improve the way of working!
A book on retrospectives from 2001 cannot bring anything new, but it's interesting to understand how the points of view have changed. The author prefers the term Retrospective over Post partum and Postmortem, and the focus is clearly on Projects. He keeps the term postmortem when dealing with failed projects. Kerth says that looking at what has not worked, and looking at the past, is not a natural activity and a Ritual is needed. He says Wayne and Eileen Strider were the facilitators who suggested the term "Retrospective". Kerth structures retrospectives into Readying, the Past and the Future, and suggests exercises for each of them. He also includes a chapter, with interesting bits, on how to become a skilled retrospectives facilitator. The most important thing of the book is Kerth's Prime Directive, sure. Some quotes from the book: - The facilitator must be an outsider. - Effective retrospectives require about three days. - The best time for the retro is from one to three weeks after the end of the project. - One practice we must agree upon is that managers will not participate heavily in the retrospective discussion. Their main responsibility is to listen and learn. - In a retrospective, I feel comfortable leading about thirty people by myself. In a postmortem, I’ll partner with another facilitator whenever the team is larger than fifteen members.
This book was a 5/5 for relevant and deep content on project retrospectives and a 3/5 on overall quality as a book, so 4/5 overall.
The target audience for this book is people running project retrospectives. It provides a wealth of material on the purpose of retrospectives, preparing for them, running them, and improving them. To a large degree, the book is targeted even more specifically at professional retrospective facilitators. The upside of this focus is that Kerth gives a broad set of tools for structuring retrospectives and discusses the trade-offs of different activities in depth.
The downside is that Kerth takes a pretty strong position on retrospectives: they should last 2-3 days (preferably 3), preferably take place offsite, and be run by someone outside of the project team. While I understand his position that, as a professional facilitator, if those requirements cannot be met, it is not likely to be worth his time to facilitate, as a lead of a team, I would have liked more discussion of how to bridge the gap between those ideal conditions and the conditions I'm likely to encounter where we don't have as much time, offsite is possible but hard, and getting an external facilitator is challenging. I suspect that even under those challenging situations, having some retrospective-like process is valuable, even if it's not as valuable as what you can do under better conditions.
Overall though, this was a valuable read for anyone interested in how to structure effective retrospectives, even if you are unlikely to have them under ideal conditions.
Книга с одной стороны рассказывает что такое ретроспектива проекта и как к ней подходить. В чем важность этой практики для команды и компании, как можно посчитать ее ценность в деньгах. Но это не только рассказ о ретроспективе в историях и примерах, а в также сборник готовых рецептов для ее проведения. В книге описаны упражнения которые нужны для подготовки и проведения ретроспективы проекта и постмортема. Планирую использовать как справочник для подготовки к следующей ретро.
The content is quite nice and the most comprehensive book about Retrospectives I've read so far. It gives some nice hints and you can see that the author really knows his craftsmanship. Still it feels a bit outdated and not that easy applicable to software development in 2020.
It is a good guide and one of the few books on the topic which handle it in a comprehensive way. If you are about to lead a project retrospective this book is a good read. If you have participated in projects, then you will see yourself reflected in many of the true stories described in the book. It is worth reading it, even if it took me three years to complete it, but this is another story.
The Retrospective Prime Directive is one of those keys to having a good retrospective, and it's important to wave it around like a weapon; a kind of shield against toxic finger pointing.
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
I will admit that Kerth's idea of a multi-day retrospective is much more in-depth than anything I've experienced, mostly because of Sprint/Scrum/Kanban's affect on the industry and cutting most work down into two-week sized chunks. Still an entirely too fun read for it's own good, and the practical examples are easy to cut down when you need to.
I think I read this book before - years ago, before I started tracking what I read on goodreads. It was good the second time too though.
Each chapter begins with a cute animal story applying the lessons of the chapter. The first was from "Winnie the Pooh." The others cover assorted interactions between an Owl, Wolf, Pig, Beaver, etc.
Each chapter is full of tips,cartoons and anecdotes. One chapter includes exercises to draw out trust and information.
I certainly got some ideas and insights for my next retrospective.
Good book about holding retrospectives. Nowadays when agile projects are more usual, I'm not sure if there is need for these multi-day retrospectives. Nevertheless techniques and facilitation skills in this book are still very useful in more agile iteration retrospectives. This book also nicely introduces some theories about how people behave and how to resolve conflicts. I recommend this for anyone interested in holding retrospectives of any kind.
Useful text on running retrospectives, albeit from someone who seems to do this work on a full-time basis. Bottom line: for a retrospective to be useful you need three days.
The book contains an overview of the whole process as well as a ‘cook-book’ of exercises you can use in various situations, including when a project has completely failed.
This is the bible for facilitators, but there are a LOT to learn even if you do small retrospectives with your team. Helped me a lot to focus the discussions in the right direction. It might repeat some of the conclusions, but I understand this is a practice because people skip some chapters. It helps you solidify them.
The best book on retrospectives I have ever read. Full of practical exercises and some theoretical grounding with lots of references. This book is much better then the Agile Retrospectives book which now appears to me as a simple rip-off of this book.