Endgame Reviews

Reviews

Value here for anyone delivering software, June 6, 2006

Reviewer:

Lisa Crispin (Denver, CO United States)

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.

Surviving the endgame, August 15, 2005

Reviewer:

Donald J. Reifer (Los Angeles, CA USA)

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.

A "must-have" resource of ideas and practical experience , April 14, 2005

Reviewer:

Midwest Book Review (Oregon, WI USA)

Written by a software team-builder of 25 years' experience, Software Endgames is a guide that focuses 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.

www.StickyMinds.com Review: by Mark L. Krug email: MKrug1@kc.rr.com
"Software Endgames" is a wonderful book. This technical book is surprisingly entertaining. The author covers all the important areas of quality assurance and process improvement. The information is well organized, straight to the point, and does not attempt to force concepts down the reader's throat. The author obviously has a good understanding of both the industry trends and the typical development lifecycle bottlenecks and hurdles. He makes the reader feel as though they come from common ground, and share the same frustrations and triumphs.

The recommendations are realistic and more grounded than most books written on this subject matter. Because it is written with short time frames and limited resources in mind, I find the information to be practical and realistic for today's software development environment. Current rapid development and short project timeframe's often pose quite a challenge to quality assurance, process improvement, and testing professionals. This book shows that it is possible to implement quality practices and processes into the development lifecycle without sacrificing valuable development time.

The author's writing style feels more conversational rather than like a technical book. The chapters flow together and cover areas of particular interest. Adequate emphasis is placed on each area within the chapters, and the examples help to illustrate the subject matter. The author also gives plenty of references to more information. The charts, graphs, tables, flow diagrams, and sample checklists all helped to solidify the subject matter.

If you are looking for a fast, efficient, and effective way to inject quality into your projects this book will certainly kick-start those efforts. "Software Endgames" is informative, entertaining, and sufficiently covers all areas of quality assurance and process improvement. So much material is covered in what seems like such a short book. The triage and change control chapter is of particular interest as this is the area that many companies have the most trouble managing. The topic of release criteria is covered very well and would be helpful to any organization that currently does not have such criterion. Readers will find the book to be a valuable addition to their library, and I would recommend it to software development professionals involved in all areas of the software development lifecycle.

So much material is covered in what seems like such a short book. The triage and change control chapter is of particular interest as this is the area that many companies have the most trouble managing. The topic of release criteria is covered very well and would be helpful to any organization that currently does not have such criterion. Readers will find the book to be a valuable addition to their library, and I would recommend it to software development professionals involved in all areas of the software development lifecycle.

ACM Software Engineering Notes, July 2005, www.acm.org/sigsoft/SEN (Digital Library)

Galen defines what he calls "the Endgame" as "The endgame is the period of software development between the testers' first receipt of the software and the customers' first receipt of the product." I shall admit to being a bit uncomfortable with this definition as it appears to leave out all those innumerable endgames during subsequent software evolution. However, with that reservation, I must say that anyone involved in this portion of a project, particularly those in the management of it (and that is, any level of management, from team leader) would definitely benefit from reading this book. How can I say it? This gentleman has obviously been there and understands the issues.

I once joined a project as manager of Software Quality Assurance when it was "deep" in testing. This was the project's first "taste" of SQA. It was a large project; a telephony system, with about 400 man-years in software. Notice, this matches Galen's definition of endgame. During testing, the project was receiving some thirty new and corrected requirements each week. Ever since, this project has been one of my definitions of a project catastrophe. (It is not the worst managed project I have seen, but close.) Galen's book is one of those where even if you only read the Table of Contents, you are going to learn from it, even if you are experienced. I could wish I had it then; what a lot of aggravation it would have saved. That, by the way, is my definition of endgame, a synonym for aggravation (end game; begin heartburn). The book concentrates on defects; their triage, removal and measurement. This includes ideas concerning work flow, configuration management, release criteria, leadership and management and a bunch of tips for collaboration - one of the big curses of endgame is that people are too tired and need to be reminded that they are one team, not working against one another. One point, I would have wished for another chapter added: something about Post-Mortem analysis.

This book was an interesting exercise. The author also did a superb job in analysing the issue and writing it up. The text is readable, interesting and never dull, with loads of examples. Their text is pleasant to read. Any book has two "parents" - the author and the publisher. The author did, as stated, a first-rate job. The publisher seems to have also performed professionally, producing a well-designed text that is nice to read (nice on old and tired eyes; another attribute of endgame) and quality was an obvious concern. The book is also well illustrated.

Yes, in short, I liked this book, Spread it around! It may get you through your next one a little healthier.

Reviewed by: Mordechai Ben-Menachem, Dept. of Industrial Engineering and Management, Ben-Gurion University, Beer-Sheva, Israel, quality@acm.org