Thedwick

Maybe it’s my (ancient history) background as an EMT, but I like to use medical metaphors to describe some common themes in software projects. If you liked my post on application guarding you might like this one, too.

Many of us have been on a project that seems to be alive with frenzied activity, but none-the-less isn’t going anywhere. To me, this sounds so much like the medical condition ventricular fibrillation that I’ve decided to dub the project version of it “Project Fibrillation.”

When someone has a “heart attack,” what they are actually experiencing is ventricular fibrillation. Their heart hasn’t stopped beating–quite the contrary their heart is alive with frantic electrical activity. The real problem is that the electrical activity has become uncoordinated such that when some cells in their heart muscle are squeezing with all their might, other cells are simultaneously relaxing. The net result is their heart expends a great deal of energy but doesn’t actually move any blood anywhere, kind of like a three-year-old wildly kicking in a swimming pool when learning to swim. All the frantic heart activity quickly uses up energy in the heart muscle and since blood isn’t moving properly that energy isn’t replaced. This negative feedback cycle quickly leads to cell death.

Sound like a project you’ve worked on?

Projects that are just getting themselves into trouble can enter fibrillation if they are not careful. A fibrillating project is one that spends much more energy on non-productive activities than it spends on productive activities. For example: a project might hit any number of minor technical snags. Most of these snags will get fixed and everyone will move on with their lives without any problem. But what if that snag were combined with a few other, unfortunate coincidences? Say the project has been going well for three months, has been setting optimistic expectations, and then exposes a minor-but-scary-looking user interface bug right in the middle of its first demo with the executive sponsor? Most likely that sponsor will start to demand more proof that the project is doing well. The development manager might start freaking out and putting his hands deeper into the technical pot or even dive bombing into deep technical discussions best left to developers. Pretty soon everyone is running around chasing real or imagined issues; often two or three different people try to independently tackle the same issue. In this kind of frenzied environment, more bugs might get created, further reinforcing the suspicions and behavior of the executive sponsor and development manager.

Fibrillating projects need the same swift treatment a heart attack needs: they need to be immediately shocked and reset.

Here are some symptoms that your project might be experiencing project fibrillation. Just like with the old “pain in the left arm” symptom of a heart attack, they might mean you’re in trouble or they might just mean you were lifting your coffee mug too fast:

1. You are asked at the last minute by several different people who aren’t talking to each other for ad-hoc project metrics that are difficult to gather at the last minute;
2. Non-technical or semi-technical project members are suddenly asking for the technical details of bugs and features;
3. The team is repeatedly re-estimating features, as if the second re-estimation will produce a different number;
4. The team starts to abandon its schedule, its process or its estimates in favor of just pushing random, impressive-looking but otherwise unimportant features out the door as fast as possible.

The treatment for this disorder is not simple but it is vital. Most importantly, the whole team needs to be gathered in a room and the fibrillation needs to be acknowledged, as well as whatever event precipitated it (if there was one). This first step goes a long way because in the heat of the moment the team may not have noticed things had actually shifted so much.

Next the discussion needs to center on facts. The facts of the situation need to be spelled out as dispassionately as they can be: “during a demo we had a bug caused by a timing mismatch between the polling thread and the UI refreshing thread. This had the visible effect of hiding a data update. The fix has already been coded by Reeti and released to the test environment. This bug escaped unit testing because unit testing does not test the interactions of the two threads.” Facts are what tend to be most important to the individual engineers on the project, but because development managers aren’t in the code every day, they do not have enough facts to fully measure the gravity of the situation.

Then, after the facts have been spelled out, perceptions of those facts need to be discussed frankly. This is the place where the development manager can explain the impact of the problem: “Sasha, our executive sponsor, has only seen our product once and that one time everything she could see with her eyes told her it didn’t work in a pretty major way. This directly contradicts what I’ve been telling her for three months now about how great the project was going and she no longer trusts me to give her an accurate read on the project.” What individual engineers often don’t fully grasp is how perceptions at an executive level are just as important as facts. Perceptions have just as much of a material impact on a project as facts: in this case a perception of instability will lead to project sponsors demanding more objective measures of progress which will lead to engineers spending there days sending progress updates in emails instead of writing code.

Lastly, when both the facts and perceptions have been acknowledged, then the team needs to come up with solutions to both. The team needs to acknowledge that they cannot avoid taking on more work as a consequence of this snafu, even if they don’t feel the work is “justified” by the facts alone. Each solution should attack the problem from a different angle. If it looks like two solutions are duplicating each other’s efforts, then they should be combined or eliminated. Then, the team can move on. The aim is to put out the fire with as little fibrillation as possible.

At the end of this process, the team has done the project equivalent of pulling out the defibrillator paddles and shocking things back into rhythm.

Of course, avoiding fibrillation in the first place would be even better. Just like there are ways to reduce the risk of heart attack, there are also ways to reduce the risk of project fibrillation: transparent metrics, frequent stakeholder exposure, and close collaboration among the team and their customers. All of these measures establish a culture of trust that helps avoid project fibrillation.

Posted on Friday, May 28th, 2010 at 4:36 pm in Technology   |  RSS feed Pinging is disabled. But you can skip to the end and leave a response.