Topic: Disasters

Compiled: 12/9/2004

The situation

Dear pmclinic,

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

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

The basics

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

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:

1. Create a list of candidates to pick up the work. Pick one. Or if appropriate, divide the work across two or more people.
2. 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?".
3. Assess which items are most important and make sure those are assigned and rationalized first.
4. Let the broader team know what has happened, what the changes are, and that they can contact you with any questions.
5. 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.

Contributors

Steven Levy, Neil Enns, John Wilger, Casey McKinnon, Jeri Dansky, Faisal Jawdat, Scott Berkun (editor)

PM Clinic discussion group

General info
How to join
Full archives
Other web forums