在Gartner最近的一篇博文中，Thomas Murphy表达了对敏捷项目变成“死亡行军（Death March）”循环的担忧。

他在文中写道，在一个历时12个月的瀑布项目中，团队可能会在前10个月过着“正常”生活，然后，迫于不切实际的交付期限和范围所带来的压力，在接下来的2个月里过着地狱般的生活。

相比而言，在每两周一次迭代的敏捷项目中：

每年可能会有26次冲刺。如果冲刺的10个工作日中有2天是死亡行军，那么每年有52天死亡行军，而在“按年计算的”项目中有40天。在死亡行军的天数上，敏捷多出25%。

他继续谈论可持续的开发速度这一敏捷原则的重要性，并在文中写道：

问题在于什么是可持续。我听说了一些故事，听上去并非只有冲刺的最后2天是死亡行军。每天都感觉是死亡行军。这不是一个新话题了，我在本文的后面列出了一些关于该话题的博文链接。组织，确切地说是团队，需要确定对于团队而言什么才是可持续，需要理解WIP限制。高速公路100%填充就变成了停车场。别让到敏捷的转换变成到不间断运行的转换。全球业务和移动设备只会使它成为一场更具挑战性的战争。

他引用了多篇讨论可持续开发速度和实际工作条件必要性的博文，其中有一篇Big Visible上的博文，讨论解决如何实现可持续：

在阅读关于敏捷的著作或者与敏捷参与者交谈的时候，我们经常听到“可持续的开发速度”这一术语。任何工作过度的人都可能会想到两点：一是，可持续的开发速度听上去很好，但不可能实现。在讨论这一术语的时候，很多人都因为相信可以在这一约束下完成需要做的工作而陷入挣扎。二是，有些人认为，软件创建与可持续的开发速度互不相容。