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