Komm süße Todesmarsch

People who’ve been in the IT field for some years tell tales of the bad old days when every project ended in a Death March. Well, actually, no one died. Truth be told, no one marched, either. But we called it a Death March. Some call it the Death March Antipattern. It was, in fact, one of the reasons people became interested in exploring alternative approaches to software development.

Younger professionals have managed to avoid the Death March Antipattern, for the most part. When oldtimers tell their tales, many of the younger folk react as if they were hearing Monty Python’s Four Yorkshiremen sketch, in which four retired gentlement reminisce about the difficulties of their youth: “There were a hundred and sixty of us living in a small shoebox in the middle of the road.” “You were lucky. We lived for three months in a brown paper bag in a septic tank.” “But you try and tell the young people today that…and they won’t believe ya’.” “Nope, nope.”

But it was real. On a typical 12-month software development project, the first ten months would be spent preparing useless documents and snoring through useless meetings. With the deadline looming, the team would scramble to get as much of the work done as possible in the remaining few weeks. It meant working 24×7 until you delivered, and then crashing for a few days. That was the Death March. And it had much in common with modern-day “agile” development practices.

Here’s what we did on a software development Death March:

• We created a War Room by moving cubicle walls and/or furniture, and forwarding our phones to that location.
• We gathered all the people who needed to have input into the solution into the War Room – business stakeholders, managers, analysts, testers, programmers, DBAs…everyone at all levels and in all roles.
• That group of people was fully dedicated to completing the project at hand, and nothing else, for the duration of the Death March.
• We did whatever was necessary to get the work done properly.
• We did nothing else – no pure-overhead, non-value-add activities.

Here’s what we do on an “agile” software development project:

• We create a collaborative team work space by organizing movable walls, configurable furniture, rolling whiteboards, and other necessary resources. The work space includes a group work area, semiprivate areas for thinking and brainstorming, and private spaces for one-on-one discussions and personal matters.
• We form a cross-functional team that includes all the skills necessary to complete the work.
• The cross-functional team is fully dedicated to the project at hand, and nothing else.
• We spend our time doing whatever is necessary to get the work done properly.
• We avoid wasting time on activities that do not contribute to getting the work done properly – no pure-overhead, non-value-add activities.

Just one thing is different…beautifully, gloriously, sustainably different: We stretch the Death March out over six months instead of cramming it into four weeks. The project that would have taken twelve months the old way is now completed in half the time, with twice the quality, and none of the stress. And we can do it again and again.