Death March Project: The Agile Death March

Agile software development. Death March projects. And now: Agile software development and Death March projects in the same sentence. Pretty scary, eh?

In his book, Death March (2nd edition, 2003), Edward Yourdon says Death March projects are becoming increasingly common. I hope that wasn’t true circa 2003, as my experience is that Death March projects were the norm throughout the 1980s and most of the 1990s.

I believe one of the driving forces behind the move toward humane workplaces and lightweight methods was the prevalence of Death March projects. Such approaches began to gain traction in the early 1990s, and became popularized after the Agile Manifesto was published in 2001.

A book came out in 1987 to explain how to run Death March projects on purpose. John Boddie’s book, Crunch Mode: Building Effective Systems on a Tight Schedule, explains how to drive a team of software developers to nervous breakdowns, cardiac problems, divorce, burn-out, and suicide as a way to deliver a project on a very tight timeline.

In the 1980s, I worked on many of these projects. I’ve known very good technical professionals who left the field permanently, whose marriages ended, whose health was destroyed, who required psychological treatment, and even one who committed suicide. I myself wasted many years when I could have been living a balanced life, and instead spent day and night pushing myself beyond all reasonable limits to deliver a piece of software whose value to humanity could never compensate for the human cost of producing it. Many thousands of people did the same.

The good news is the Death March is no longer the norm in software development. I’ve met many younger colleagues who don’t relate to the lifestyle of perpetual 90-hour work weeks. Most of them don’t even believe the tales told by their elders, bless their little hearts.

But there’s bad news, too. That “crunch mode” book is popular among managers today. It has a five-star rating on Amazon. Reviewers think it’s great that there’s a way to break every model of sustainable delivery, planning, and estimation, and force people to deliver on an arbitrarily short timeline regardless of the human cost.

You might say a Death March could be justified if the solution’s value to humanity were great enough to offset the human cost of building it in an inhumane way. The case study presented in the book is of a betting application for a casino. It helped casino owners extract money from gambling addicts in the same way as drug dealers extract money from drug addicts. I leave it as an exercise for the reader to judge whether the value to humanity justified the human cost exacted from the development team. Opinions differ, it seems.

So, what happens on these Death March projects, anyway? In my experience, the following things happen:

• Management explains the importance of the project to the staff and asks for volunteers.
• People volunteer for their own reasons, but mainly because they are excited about the challenge.
• A team is organized from among the volunteers, representing all the skill sets and responsibilities necessary to deliver the solution.
• A “war room” environment is set up and the team is located there for the duration of the project.
• Administrative boundaries that normally divided functional silos, management hierarchies, and the like are suspended for the members of the team; everyone can communicate directly and in person.
• Rank, formal hierarchy, titles, and the like are temporarily suspended within the war room for the duration of the project.
• Stakeholders are present in the war room throughout the project and they provide the team with immediate clarification and feedback about needs and priorities.
• The scope of the work is so large compared with the available time that the team dispenses with conventional planning and estimation. They dive right in, focusing on the functionality directed by the key stakeholder.
• The team delivers as much of the most important functionality as they can within the allotted time. If any key functionality remains unfinished, they cover for it manually while continuing to tie up loose ends after the delivery date.
• To be sure they can get as much work done as possible, the team uses methods and techniques they know are effective, and they dispense with activities that don’t directly help them deliver.
• When the project ends, the survivors crash for several days to recover from the exertion. The days immediately following the project are not normal work days. Some of the survivors decide to change jobs or change careers. Others take care of their new health problems or their divorces. Those who escape with most of their sanity intact swear that they will never again participate in a Death March project. They will not be available the next time management asks for volunteers.

Now consider some of the key characteristics of Agile software development:

• dedicated, volunteer team
• collaborative team workspace
• all skills and roles represented on the team
• collective ownership – hierarchy and silos are blurred or nonexistent
• constant or iterative planning throughout each project
• focus on top priority work item as defined by a key stakeholder
• team members use methods and techniques that help them deliver, and dispense with non-value-add activities
• team delivers maximum amount of value possible in the allotted time

The main difference between an Agile project and a Death March project is sustainability. There’s an emphasis on sustainable pace in Agile methods.

Another difference is the recognition of the value of human beings. Agile methods tend to consider human factors, while the Death March approach treats humans as resources or “things.” It doesn’t matter if someone burns out and quits the field, loses their family, or commits suicide. All that matters is on-time delivery…and it’s one-time delivery, too. What may happen afterward is of no concern to the Death March manager.

There are more similarities than differences between Agile and Death March projects. What does it mean?

I think it means we can consider an Agile project as a Death March project that is stretched out over time. If a 1980s-style project consisted of nine months of meetings followed by a three-month Death March, then an Agile project might consist of six months of slow Death March. We deliver in half the time, with a strong focus on customer-defined value, close alignment with stakeholder needs, effective use of practical methods and techniques, and close collaboration and teamwork.

If people are doing only the things that directly help with delivery during the Death March, then why waste the first nine months in non-value-add activity? Why not just skip straight to the Death March phase, and stretch it out so that it isn’t stressful?

Without the stress, people don’t have to seek medical help, change careers, start new families, or be buried. The team can continue to work on the next project in a sustainable way. The organization doesn’t have to try and re-market itself so that people are willing to work there.

There’s a common mischaracterization of Agile as “going faster.” If all you really want to do is “go faster,” you’re looking for the Death March approach, not the Agile approach. Good luck with that.