PM Clinic: Week 9 Summary
Recently my web development team did an exercise in disaster planning. We sat down
as a group, came up with a short list of things that could go wrong, and then tried
to brainstorm on how we'd respond (It was a lot of fun and y'all should try it.. but
One of the situations we came up with that generated the most discussion was this:
"3 weeks away from your next major deadline, your best programmer gets hit by a
bus, and is in a coma. You're on your way back to the office from the hospital, trying
to figure out your next moves. What would you do and how would you roll those decisions
out to your team?"
- Cross on the green not in between, San Jose
Don't forget the human issues. If someone on the team leaves the project for any reason,
particularly for because of serious illness or death, there will be morale and psychological
impact. As a manager, it's your job to manage this and help people to deal with it.
Support people in a way to grieve if necessary, and make some kind of counseling available
(some health plans support this - if so, make sure your people know about it. If not,
find a name of a good crisis councilor, or therapist).
Find out if HR does anything to help the programmer's family (make sure followers are
sent, etc.). On the whole this doesn't necessarily demand a huge investment of your
time: just make sure everyone understands that grieving is normal, feelings about loss
is normal, and that there are services that can help people deal with whatever they're
Disasters are not the only situation that demand disaster planning. Between family
emergencies, illness, people changing jobs, etc. all managers deal with unexpected roster
changes all the time. So while it might not
always be as dramatic as the example given, it's a fairly common kind of situation.
Chad pointed out that from a purely systematic view, the loss of a programmer is a
loss in productivity. The team will no longer be as productive as it was. Whether the
programmer was the best or the worst doesn't really matter: either way the planned productivity
for the team will
have to be recalculated. The larger the change in planned productivity, the more re-planning
of estimates and schedules that will need to happen.
Steven explained that part of the managers job should be to set up people to step up
into larger shoes when necessary. Not everyone can be a Paul McCartney or Eric Clapton
(btw:: I think Steven was showing his age with these references :) Part of the superstar
programmer's job should be to mentor someone else, and make sure other people in the
org understand the spirit and heart of the work they were doing.
Rough process for managing the situation
Here's an outline for how to respond:
- Create a list of candidates to pick up the work. Pick one. Or if appropriate, divide
the work across two or more people.
- Figure out who will be impacted by the change in work assignments, and how they
will be impacted. This is best done by talking to them directly and finding out what
their concerns are. "Fred has left the team, and Sally is going to pick up the
work. Do you have any concerns about this?".
- Assess which items are most important and make sure those are assigned and rationalized
- Let the broader team know what has happened, what the changes are, and that they
can contact you with any questions.
- Let the customer know about what has happened, what the changes are, and that they
can contact you with any questions.
John pointed out that strong teams manage change well - Agile processes are built around
this: the team owns the project, not components of the project. So if the leaders have
built the right spirit, the team will naturally and
instinctively rally around whatever decisions need to be made to bring the project back
to a healthy place. Neil suggested that in many organizations teams change often, and
the reason for a new change doesn't really have an
additional negative impact- it's just another course correction.
Additional insurance against disaster
There is a long list of development practices that have a side effect of insuring against
disaster. Two worth calling out:
Code reviews / Pair programming: Theses are two flavors of the same brand of ice cream.
Code reviews the mild wimpy kind, and pair programming the full on over the top kind.
They both involve two programmers sitting down and
working on stuff together, sharing knowledge and understanding to improve the way the
code is written. Both improve the odds that someone other than the guy that got hit
with a bus will be able to pick up the work.
Documentation: Any technical specs or UML diagrams that define how the code is structured
can help the team pick up where the developer left off - assuming of course they were
written in a way someone other than the author can understand. In a very rough sense
a bug database with all of the programmer's active issues will help significantly in
someone else picking up his work.
Random group psychology observations
We wondered why some organizations, like sports teams, rally around fallen comrades,
and others don't. Some thought it was all about how leadership responded to the situation,
and what core values motivated the company. It's not uncommon for sports players to
wear the number of an injured or sick player, or wear black arm bands to represent them.
Steven Levy, Neil Enns, John Wilger, Casey McKinnon, Jeri Dansky, Faisal Jawdat, Scott