Rescuing a Failing Project

So if one practice is good, then all of them must be better, right? Eventually, yes, but not all at once—and especially not if the project is already in trouble. Changing all your development practices on a project at once is the best way to kill it.

To use a medical analogy, suppose you have a patient with chest pain. Of course, if the patient exercised regularly and ate well, they wouldn’t be in trouble. But you can’t just say, “Get your butt off the bed, and start running on the treadmill.” That would be fatal and surely cause your malpractice insurance rates to rise.

You have to stabilize the patient using the minimum (but essential) medicines and procedures. Only once the patient is stable can you offer a regime to maintain good health.

When a project is failing, you’ll want to introduce a couple of practices to stabilize the situation first. For example, Venkat once got a panicked call from a prospective client; their project was in shambles. They had spent half their allotted time and still had 90% of the project to deliver.

The manager was unhappy that the developers did not produce enough code fast enough. The developers were unhappy that the manager was pushing too hard. Should they spend the rest of the day fixing bugs or writing new functionality? Despite the depth of the crisis, the team was genuinely interested in succeeding. But they didn’t know how. Everything they did put them further behind. They felt threatened and weren’t comfortable making decisions.

Instead of trying to fix everything all at once, Venkat had to first stabilize the patient, starting with communication and collaboration-oriented practices such as ​Criticize Ideas, Not People​; ​Schedule Regular Face Time​; ​Share Code Only When Ready​; and ​Keep Others Informed​. From there, the next step was to introduce simple release practices such as ​Keep It Releasable​, and ​Integrate Early, Integrate Often​. Finally, they started a few helpful coding practices such as ​Warnings Are Really Errors​, and ​Attack Problems in Isolation​. It was enough to avert the crisis; the project was completed two weeks ahead of schedule and received acclaim from higher-level managers.

That’s the emergency rescue model. If things aren’t that dire, you can take a fuller, more measured approach to introducing agile practices. We’ve got some ideas for you depending on whether you’re a manager or a team lead or whether you’re just an interested programmer trying to lead from within the organization.