How to Understand and Relieve the Symptoms of “Agile” Death Marches

Did you ever work on a project that dragged on and on, slipping a week every week? Back in the day, we called those projects “death marches.” I never saw anyone literally die, but I saw too many divorces, abuse of drugs and alcohol, and very dissatisfied and unhappy employees and customers.

Waterfall projects can turn into death marches because we don't get feedback until the end of the work. (That's when we see the 90% Done schedule game.) However, too many supposedly-agile projects can turn into death marches, too.

Here are the symptoms I see:

  • Someone asks the team to commit to more work in an iteration. This person is often a manager who feels pressure. In my experience, the pressure is real, so saying, “Don't succumb to pressure,” doesn't work.
  • As a result of the pressure, management often asks the team to shortcut technical excellence, believing they can trade that excellence against time. That never works.
  • When teams don't focus on technical excellence, they create problems along with features. Too often, to “save time,” the managers ask teams to postpone any fixing until after the release.

When teams work this way, they don't create great products. Instead, they create barely functioning products full of cruft.

When managers succumb to pressure, they make decisions that create death marches under the guise of an agile approach. The pressure causes many of these problems.

Relieve the Pressure

If you see this problem in your organization, you have some choices to relieve the immediate pressure:

  1. Measure cycle time, so everyone understands a team's capacity. (If you also want to measure story points, I won't stop you. But story points don't help people see the duration of the work. See Measure Cycle Time, Not Velocity for more details.) Once you measure the cycle time, you have data to explain why the work takes the time it does.
  2. Make sure everyone on the team works on this—and only this—product. (See Focus on One Thing at a Time or the project portfolio tag on my site.)
  3. Instead of committing to work in some time period, focus on one or two of the most valuable features and ask the team to collaborate and finish those. Then, start the next one or two features. Yes, that limits WIP (Work in Progress). If you notice the work taking “too long,” ask everyone on the team to focus on this one feature. If the feature still takes too long, split it so the team can release some value and continue.

That will relieve the immediate pressure, but not fix the underlying causes. Every environment has its own causes.

Observe the Environment

In the space of two months, Fred, an agile program manager, saw the program cycle time increase from several days to several weeks. Worried, he asked the teams to map their value stream to understand their delays.

The teams showed delays because each person had additional projects and work—not just the program work.

When Fred asked why the teams took on other work, he learned the managers had requested this new work. HR had created a new compensation system for the managers. In that system, each manager had personal deliverables. Since the managers couldn't develop products, the teams—working as individuals—were supposed to deliver.

Fred used a multi-pronged approach. He first asked the teams to collaborate on just one or two items at a time as a team. Fred wasn't sure that limiting WIP (Work in Progress) to one or two features was the correct number, but it would help the teams finish the work and get the program back on track.

In addition, he met with HR and senior management to explain the effects of a manager's personal deliverables. HR agreed to stop that system.

Agility Requires Culture Change

I'm sure everyone was trying to do their best work, including senior leadership, HR, with this introduction of a new compensation system.​ However, the more an organization focuses on any individual and his/her work, the less agility the organization can gain.

The more we focus on an individual, the more we optimize for the individual, and the less we focus on the flow of work at any level. I often say, “Optimize up.” Focus on how the team can release the product as fast as is reasonable. Then, focus on how fast managers can decide so the teams can do their work. Finally, focus on the strategy: which customers the company wants to serve, with which products, and when.

You can have teams work in an agile way. However, if you want to avoid death marches, you'll need to address the focus of the organization. Do you want to “hold people accountable?” Or, do you want to focus on the flow of work to create organizational success?

Death marches are not agile. Instead, create an environment where everyone can do their best work as teams. Optimize up, for the product or a greater purpose that will serve the entire organization.

(Some readers have asked I continue to describe where to find more information from my books. This newsletter touches on topics in Create Your Successful Agile ProjectAgile and Lean Program Management, and all three Modern Management Made Easy books. Do you like seeing this information?)

Learn with Johanna

I opened registration for the Q2 2022 Writing Workshop. If you want to become a better nonfiction writer, please register now. Or add yourself to the mailing list for a future workshop.

New to the Pragmatic Manager?

Are you new to the Pragmatic Manager newsletter? See previous issues.

Here are links you might find helpful:


© 2022 Johanna Rothman

Pragmatic Manager: Vol 19, #2, ISSN: 2164-1196

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: