敏捷项目多死于交付压力
敏捷并不是保证交付的银弹，敏捷也从来不是提高交付速度的工具，敏捷和其他所有项目一样，当交付压力过大时，很可能面临失败。因为敏捷的迭代化特征，使这个交付压力从第一个迭代就能体现，而如果这个交付压力不能够很好的解决，比起传统瀑布式项目来说，更容易造成失败。
传统的瀑布式模型对交付压力的反应最慢。在整个开发期中，交付压力的体现往往需要到后期才能显现——所有人都在工作，谁也不知道能不能完成，这也是为什么延期成为传统软件开发最经常碰到的事情。但是这样的交付压力并不在项目的大部分时间被开发人员体察，于是“做不完怎么办”的忧虑对团队影响比较小，交付压力往往并不是导致瀑布式模型软件开发失败的关键原因，真正的关键原因是在于需求失真，最后的成品不满足客户需要。
而敏捷项目的迭代开发，每个迭代团队能够交付的交付量较为固定，在一个发布期中，很容易发现是不是能把所有需求交付。按照计划工作量平均分配给每个迭代的工作量如果产生遗留，自然意味着按照这样的速度，如果没有新资源，我们肯定要延期或者赶工。这样的忧虑很容易从第一个迭代就满布在团队当中，最后甚至会演变成，反正都做不完，那我再怎么努力也没有用，倒不如随便一点。
敏捷的优势在于随时可以发现对项目交付的风险，交付压力作为其中最重要的一个指标之一，需要团队管理人员进行处理。交付压力过大的最大体征是每个迭代都有较多遗留Story产生，这些遗留Story很多情况都流入下一个迭代，结果可能是使下一迭代的遗留Story更多。另外一个发现交付压力过大的可视化工具是燃起图，如果把交付范围到原点画一条直线，比较“故事完成”点数趋势线，如果后者的斜率远远小于前者，说明整个发布的交付物一定远小于计划交付量。
是隐藏坏消息还是公布坏消息？公布坏消息的原因在于希望及早解决，或者提前让客户降低期待程度，如果只是单单展示而不做动作，这种展示本身可能就是坏消息。也许“请化交付压力为工作动力”在某种情境下正确，可软件工程不是给小学生辅导功课，它应该是一种可度量可管理的科学，对于项目的某些关键体征，应该用一种科学的态度去应对，项目管理的核心还在于用优化的流程和行为方式消除组织中浪费以及配置合理的资源，而不是一味激励和思想控制。国人的语境环境里有太多“又快又好”、“人定胜天”、“遇到困难顶着困难也要上”的感性，而缺乏科学的严谨态度，这种“跃进”式思维导致的结果往往是“越来越快地越来越烂”，因为“快”可以非常直观的体现，而“好”却要经历很长一段时间才能体现。
敏捷的迭代式开发也许让我们沮丧，因为我们再也没办法尝试对程序员隐瞒我们交付压力过大的事实，而领导者要做的其实很简单，不管用什么办法，让团队拥有最合理和最现实的交付压力，这样的结果一定不是又快又好，但一定是在合理的速度下达到合理的质量标准。领导者们，你们在某种意义上来说不是团队的领导者，而是团队的保护者，敏捷是帮助你随时发现团队危险的工具，请把你的团队保护好，不要它从一开始就死掉。
这是软件工程，胸口碎大石的活动只可以偶尔搞一搞。