Doomed projects give everyone involved a bad reputation.
All this talk of the end of the world on May 21st, made me think of “death march” software projects. I’ve been involved in a few and they are not fun. Can an agile team using Scrum, XP, Kanban, Lean or any other agile approach, completely avoid a death march?
In simple terms, a project on a death march is one that is doomed to fail — and the teams knows it. Ed Yourdon defines a death march as a project that exceeds normal parameters by at least 50%. That could mean that the schedule is compressed by 50%, the staff is reduced by 50%, the budget is half of what is needed, or the scope is twice what is reasonable.
Teams that start a project with a reasonable schedule, adequate people, ample budget and achievable scope may also become death marches over time as deadlines are missed, priorities are changed, staffing is reduced, etc. What seemed like a normal project at the outset degrades into an impossible mission over time.
The team is thus expected to work 12-14 hour days, six days a week to complete the project. Is this unreasonable? Yes. Does it happen? Yes. Can it happen to an agile team? Yes.
Don’t let emotion rule.
Death marches usually occur when a company’s management panics. Emotion governs decision-making. There may be a hidden belief that if you push people hard enough, they’ll rise to the occasion. (And they will if the potential reward is big enough.)
Some people even like death march projects. There can be a thrill factor as you strive to do the impossible and become a hero. The heroics are fine in short bursts to meet a tactical deadline but they will wear you down over time.
If you find yourself assigned to a death march project from the outset, speak up. You need to get everyone on the team to recognize the futility of launching the project with the current parameters. Then, the team needs to approach management and educate them on the problems faced by the project.
If your project has degraded into a death march, your team needs to stop and replan. Everything should be re-evaluated — schedule, people, budget, scope, technology, design, etc. The project needs a new beginning.
New project or existing one, agile or not, the team has to provide options to company management. What are the alternatives? What can be accomplished within the given parameters? What should be sacrificed?
Speak up. Be prepared to listen and compromise. Don’t just march along to the inevitable.