Our Blog Excerpts Savings Contact


Dorset House Publishing
High-Quality Books on Software Engineering and Management.  Since 1984.
dorsethouse.com > features


iDH Sign-Up

Get Our e-News
Delivered by FeedBurner

The Dorset House Quarterly Interviews

Robert Galen
Author of Software Endgames: Eliminating Defects, Controlling Change, and the Countdown to On-Time Delivery

ISBN: 978-0-932633-62-0  
©2005  328 pages   softcover  
$33.95 (plus shipping)

Bob Galen

DHQ: Peopleware coauthor Tim Lister calls you an endgame veteran and hails your proven, practical advice. What exactly is the endgame? When does it begin and end?

Galen: I consider the endgame as the period starting when a software project is first released for external testing, and ending when it's available to your customer. External testing in this case probably implies release to a non-development testing group. It's a period primarily focused on requirement validation, testing, defect repairs, software change negotiation, and iterative releases.

DHQ: You say in your new book, Software Endgames, that very little work has been done on triage and endgame management practices. Why do you think that is?

Galen: There's been much more focus on how software is structured and built rather than on how it actually gets finished and released. I think people have this "beginning focus" because software structure and methods may seem more glamorous or interesting. While beginnings are important, I consider it an art and a challenge to actually finish what you've started. The endgame is the more practically focused and workmanlike part of building software. Anyone can start, but finishing what you started -- successfully -- is much more difficult.

DHQ: You describe your initial impression of the endgame as a chaotic, reactive period. How did you find an orderly way to manage the endgame?

Galen: I don't think you really manage it per se. What I try to present is a set of practical tools and techniques that essentially guide teams through the chaos, so they can make sound decisions and take the right steps to winnow down change as they stabilize a product for customer release. You donŐt manage or plan your way through an endgame. Rather, you firmly and decisively guide your way through it -- making decisions that map to the core requirements for the project.

DHQ: What exactly is defect triage -- and does it involve doctors and stretchers?

Galen: It doesn't involve doctors or stretchers, but you're close. I borrow the term "triage" from the medical profession -- it's the decision process doctors use when faced with more than one patient in need of emergency care. Doctors are required to triage injuries into categories of criticality before deciding who needs treatment first. The same categorization and action-taking steps can be applied to the prioritization of software defects -- particularly when you've got lots of the little buggers. Triage decision-making concepts map quite well to the endgame.

DHQ: You state that triage and change management are vital to a successful exit from the endgame. Why is that so?

Galen: It's all about deciding what to fix or add and what not to, as you approach release. You typically get hundreds of defects and many enhancement requests -- many more than most teams can implement while delivering the software in a meaningful timeframe. Selecting which features to deliver and guiding the team toward fewer and fewer changes over time are crucial skills in stabilizing any software project and readying the software for release. I've seen so many teams struggle with either doing too much or too little, only to miss the overarching goals of their projects.

DHQ: What are the worst things people do during the endgame?

Galen: I'd break "people" up in this case into two categories -- the team members proper and then the management team. From a team member point-of-view, I think the worst thing you can do is too much. Try to deliver too much, repair too much, work too much. I use the term "youthful enthusiasm" to indicate this tendency I've seen within teams. It's much better to drive toward realistic goals that map to the historical capabilities of the team. From a management perspective, I focus on two potentially terrible patterns. First is driving blaming or other dysfunctional behaviors within the team if things aren't going right. I consider it management's job, or a key leadership responsibility, to keep a level head no matter what is going on. The other major mistake is driving too much overtime. Overtime is considered unavoidable in the endgame, yet it's probably the single biggest cause of failure.

DHQ: You state that the endgame is a microcosm of the overall development process. How so?

Galen: If you think about it, in the endgame you are managing iterations of the complete development process -- requirements; construction and repair; testing and deployment. Granted, you are only working on small defects or enhancements or delivering late bits of functionality. Nonetheless, all of the standard software development methods and phases are there. It's a wonderful opportunity to observe your processes in the "small and urgent" arena of the endgame. And since it repeats so frequently, it's a good place for making small adjustments -- checking for what works in your corporate and project contexts.

DHQ: Tell us about the importance of attendance and punctuality at meetings.

Galen: I've always been a stickler for well-run meetings, whether endgame-focused or not. I guess it's the practical side of me that doesn't want to waste everyone's time, and the efficiency expert side who wants to maximize focus and effort. I think it's just plain rude to be late for a meeting where you are a key contributor. That lack of professionalism and focus then cascades over every endgame activity.

DHQ: What rules of thumb can you give us for prioritizing change requests in the endgame?

Galen: The only rule of thumb is to create a project rule of thumb to guide your prioritization. Each company has different needs and drivers for their prioritization scheme. In a Web portal project, performance would probably be very important, while in medical systems, safety issues would take precedence. What is important is for the team to determine their release criteria and the defect and enhancement prioritization rules -- in advance of the project. That way, when the heat is on, they have already set up guidance mapping to the overall project goals and key requirements.

DHQ: What's the best way to turn down change requests -- to say no?

Galen: Actually, I really emphasize not having predefined or binary responses to change requests within the endgame. I believe the more flexibility you have, the better. So, promising to fix something in a subsequent release becomes a viable option for handling change requests. However, you should create as many options as possible. For example, you can implement only part of a request now and defer bits until later releases. Some requests should never be met, so an absolute no is viable as well. I always try to get to the "true need" behind any change request. If it's truly required for a product to be successful, then I try to accommodate the request in full or at least partially. Flexibility and breadth in your response is the key.

DHQ: What's unique or different about the endgame in an agile software development process?

Galen: First of all, some of my recommended processes need to be scaled to support much shorter release points or iterations. That's probably the most obvious change. Another is focusing more on self-directing teams when applying the book's endgame guidance techniques. I'll give you an example. In the book, I propose that the development manager assign defects in a "work queue" fashion for each engineer on the team. This is one of the more controversial recommendations I make within the book. Within an agile team, I think the same approach applies, but the team members should probably select their defects with some simple guidelines to influence balance. As long as the spirit of my recommendation is maintained, I think these sorts of adjustments are perfectly fine within an agile context.

DHQ: In a systems or software development department or organization, who would most benefit from reading Software Endgames?

Galen: I've operated in three primary roles that influenced the audience target for Software Endgames. I've been a software project manager, a software development manager, and a software test manager. Sometimes, I've been bits of all three at once. I think there are lessons for all three of those functional perspectives in the book. If there is a true primary focus, it would be toward the project manager or anyone tasked with leading projects and teams through an endgame.

DHQ: What one lesson from Software Endgames would you most like the reader to take to heart?

Galen: The key is to set up structures that illuminate the goal and guide the team. Then, get out of the way and simply guide the team toward success. In many ways, the agile methodologies have come to the same conclusion -- with the notion of self-directing teams. My best endgames have been all about the team directing itself toward a clear set of goals and objectives. Inevitably, I'm always amazed at the power of technical teams to meet a challenge and succeed. A good endgame leader's job is to set the compass and guide the way, but not get in the way.

DHQ: You describe the endgame as the most magical moment in a software project. What advice would you give project managers who loathe this stage of software development?

Galen: I would encourage them to take the book's lessons to heart and make them their own -- adapting and applying them to their own endgames. What makes an endgame magical is the level of challenge and the thrill of a successful navigation and subsequent product launch, not only for the project manager, but more importantly for the team. To me, there is no greater thrill than guiding a team from a position of "impossible" to "release" by traversing a tough endgame.

DHQ: Tell us about your current work and activities.

Galen: In the last few years, I've focused on the endgame from a testing point of view. It's interesting because I've learned that the testing role -- at least in certain contexts -- seems to have a limited capacity to properly influence the endgame. I believe that within the software development management and project management functions, there is more natural capacity to have influence, so I encourage those managers to engage their testing teams during their endgames. As I mention in the book, testing teams are the secret weapons of the endgame, and my experience in the past few years has only underscored that view. That being said, I'm still learning and growing from my endgame pursuits and from sharing lessons and experiences. The book is opening more doors in this area. I'm also looking forward to ongoing endgame collaboration and lessons -- sharing via our discussion Yahoo group. For information on how to join, check www.rgalen.com.   I wrote this book because when I first began software testing, I had previous experience in testing complex hardware systems. Had I just followed that model, I wouldn't have realized the criticality of beginning test planning during requirements definition.


AddThis Social Bookmark Button





COPYRIGHT NOTICE: The material contained in this file may be copied or distributed freely, provided that the material is copied or distributed in its entirety, including this Copyright Notice. This material is Copyright © 2002 by Dorset House Publishing Co., Inc. No use may be made of the material without acknowledgment of its source: Dorset House Publishing Co., http://www.dorsethouse.com, info@dorsethouse.com, New: 3143 Broadway, Suite 2B, New York, NY 10027 USA. Additional rights limitations apply, as presented in the Legal Disclaimer posted at http://www.dorsethouse.com/legal.html.






New:3143 Broadway, Suite 2B  New York, New York 10027  USA
1-800-DH-BOOKS or 212-620-4053, fax 212-727-1044

Copyright © 1996-2008 by Dorset House Publishing Co., Inc. All rights reserved.
Home | Blog | Savings | Stores | Features | Titles | Authors | Subjects | Orders | About | Contact | Legal