| 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.
| 
