Customer Reviews

Software Endgames: Eliminating Defects, Controlling Change, And The Countdown To On-time Delivery

5 star:		(3)
4 star:		(0)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

Endgame is about what to do when the pressure is on and release is imminent, funds lacking, people leaving and defects pervasive. What I like about this book is it is current, pointed and focused on what you can and can't do when faced with the endgame. Galen gives you advice on how to avoid going crazy during the endgame based on sound logic and practical experience. The book is about defects and what to do to minimize them. It suggests that the worst thing that you can do in the commercial world is release a product to market on schedule that is full of bugs. Those who have tried it have wound up regretting it because they have had to face the wrath of their customers and users.

The book starts by providing five Chapters that explain endgame basics. It emphasizes how to make the Change Control Board work for you by setting release priorities and getting rid of defects. It discusses how to establish release criteria and use them to reduce the release's rate of change. It focuses on the role of defect and change management and how they help you to improve both your quality and readiness to deliver. The use of a working view to improve decisions by considering the interaction of variables like scope of the deliverable, its cost, the quality, time-to-market, and team motivation and teamwork is extremely powerful.

In the next grouping of Chapters, it introduces you to the basics of defect tracking and using defect rates as a management tool during the endgame. I especially like how it homes in on ways to fix defects after you have found and prioritized them. It suggest using concepts like daily builds that resonate well with those who have used agile methods to get products to market quickly by using short, focused development sprints.

In the third grouping of Chapters, it takes you through the endgame workflow. It discusses the work queues and defect repair cycle. It provides guidance on how to estimate and schedule defect repairs when using both conventional and agile programming practices.

The final group of Chapters presents materials on leadership, management practices and endgame retrospectives. The goal is to convince you that you can deliver a quality product on schedule if you stick to your guns and use the guidance provided by the book. The concepts presented are current and sensible. For example, it highlights the use of war rooms and daily meetings as team building and communications tools.

This book is a book worth reading. Again, it is a book about defects and what to do about them. It is a book that you can use whether you are using either lightweight or heavyweight development approaches. It is a book that should be on your reading list because it can help you avoid buckling to pressure and delivering poor quality products prematurely to market. All you have to do is stick to your guns during the endgame and do what you believe is right using the defect data and trends that it recommends you collect throughout the development.

Written by a software team-builder of 25 years' experience, Software Endgames is a guide that focues on the "endgame" phase of software development - the final stage between beta testing and release to the customers' market. Skillfully overseeing defect repairs is critical during this phase; Software Endgames discusses means to ensure that the best possible product is completed. Chapters address how to develop appropriate release criteria, creating a stable framework and time table, useful and relevant metrics, a variety of techniques to fix defects, management dynamics, leadership practices, and much more. A "must-have" resource of ideas and practical experience ideal for anyone responsible for overseeing software development.

This book teaches techniques that can be applied in a wide variety of situations, no matter what software development approach is being used. Explanations are thorough enough for newbies, but there are new ideas even for old hands such as myself. Readers should note the author's words of caution for each practice he describes; for example, he warns the reader to not get stuck on role definition, that it's not intended to limit contributions.

What I like about this book is that it doesn't advocate any rigid process. Rather, it gives a lot of useful techniques, such as meeting guidelines, and lots of examples, both good and bad. There's plenty of good advice, such as understanding release criteria, expecting them to change but using them effectively. I liked the suggestions for measuring progress, using big visible charts and keeping the release framework up to date. There were many terms I hadn't heard before, such as the "Duct Tape" defect category, that really got me thinking in new ways. There's also advice that can't be repeated enough, such as not letting email replace simple, direct communication.

I found a few things hard to follow, such as how methodology affects trending in the metrics chapter. But I appreciated discussions such as how to use metrics for process improvement, and estimation techniques.

There's plenty in the "Endgame Toolbox" to help just about any team. It's easy to read, and delivers value to anyone involved in delivering software.