In a recent Gartner blog Thomas Murphy raises the spectre of Agile projects becoming continual Death March cycles.
He says that in a 12 month waterfall project teams may have 10 months of "normal" life followed by 2 months of hell as the pressure is on to deliver to unrealistic deadlines and scope.
In contrast, in an Agile project with two week iterations:
That is a possibility for 26 sprints per year. If two of the working days of your 10 day sprint are a death march, that is 52 days per year vs. 40 days in the “annual” program. A more than 25% increase in death march days
He goes on to talk about the importance of the Agile principle of Sustainable Pace and says
The question is what is sustainable. I am hearing stories that don’t sound like only the last 2 days of a sprint are a death march. Every day feels like a death march. This isn’t a new topic, I have included links below to some posts on the topic. Organizations, actually teams, need to determine what is sustainable for the team. WIP limits need to be understood. A freeway filled to 100% capacity is a parking lot. Don’t let a shift to agile mean a shift to constant running. Global business and mobile devices only make this a more challenging battle.
He references a number of posts which discuss the need for sustainable pace and realistic working conditions, including a discussion on the Big Visible blog that tackles how to achieve sustainability:
When reading literature about Agile or talking to practitioners we often hear the term “sustainable pace.” Anyone who is overworked might think two things: Sustainable pace sounds wonderful and impossible. Upon discussing the term, many people struggle with believing that the required work could be accomplished under this constraint. Some think that software creation and sustainable pace are mutually exclusive.
He is far from the only commentator talking about these things. Last month Ben Linders posted an InfoQ news item looking at how to achieve a sustainable pace.
Community comments
Gartner can't seem to say anything sensible about anything.
by Stephen Anderson,
Death marches in Agile
by First name Last name,
Re: Death marches in Agile
by C Curl,
Re: Death marches in Agile
by Jonathan Harley,
Re: Death marches in Agile
by C Curl,
Re: Death marches in Agile
by First name Last name,
Agile can´t fix it
by Ralf Westphal,
Gartner can't seem to say anything sensible about anything.
by Stephen Anderson,
Your message is awaiting moderation. Thank you for participating in the discussion.
That is not Death March he's describing, it's Crunch. Death Marches can be slow, and often are. In fact, that's the worst kind - the slow, dreary, inexorable grind of a project that everyone apart from the sponsors know is going to fail.
So, does Agile lead to more Crunch? If you ignore the Agile principle that you cannot control scope, budget and timescale simultaneously. If you're doing Agile In Name Only. If you think the software fairy fixes your project if you click your ruby slippers together and say "Agile" three times, instead of following the processes that actually make it work.
Death marches in Agile
by First name Last name,
Your message is awaiting moderation. Thank you for participating in the discussion.
The article is a blog post, not a real Gartner research finding.
Scrum is Agile, and yet there are no death marches at all, 0% because when the iteration is finished, whatever didn't fit in it is transferred to the next iteration. This is the evidence that the blog post is an oversimplification and is not always true.
Agile can´t fix it
by Ralf Westphal,
Your message is awaiting moderation. Thank you for participating in the discussion.
Another example for an aspect of software development agile cannot fix.
It´s a) the basic belief that 100% utilization of a resource is a good thing.
And b) it´s the belief, software development is about craftsmen hammering away on some slab of requirement stone.
Both beliefs must be attacked from other angles.
Re: Death marches in Agile
by C Curl,
Your message is awaiting moderation. Thank you for participating in the discussion.
So Agile methodologies like Scrum are immune to becoming death march projects?
Wow.
Re: Death marches in Agile
by Jonathan Harley,
Your message is awaiting moderation. Thank you for participating in the discussion.
Not immune, but designed to resist them - done properly.
Re: Death marches in Agile
by First name Last name,
Your message is awaiting moderation. Thank you for participating in the discussion.
Scrum does not have deadlines, hence no death march. In scrum, we measure team velocity and estimate relatively how many iterations we need to clear all backlog tasks. This estimate is something like ETA when downloading from the Internet. Everybody knows that time remaining: 30 seconds can actually take tens of minutes, or longer. That's how it is designed. Consider the measure only as a useful heuristic which gives at least some progress indicator. Some heuristics is always better than nothing.
P.S.: the only person I've ever seen implement Scrum properly is me. Have you seen any company measuring team velocity, sizing tasks like t-shirts, and coming with the ETA based on latest data? Companies don't get anything right, they even fail with something as simple as agile standups. Their standups turn out into discussing tasks in detail, and taking 30m+.
Re: Death marches in Agile
by C Curl,
Your message is awaiting moderation. Thank you for participating in the discussion.
I had this crazy idea that all project methodologies were designed to resist death marches - when done properly.
It's when the constraints placed upon the project overwhelm its capacity to deliver, and people still push on, it becomes a death march.