Does Agile Drive Death March Projects?

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.

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.

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.

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+.