公司们正在尝试敏捷方法，研究它能带来的好处。然而来自高层的声音却在高声叫道：“我要见到真金白银。”要改变大型组织交付软件的方式，就跟让油罐车转向一样，有这个可能，但是要花不少时间和力气。管理层要确认：对于驱动每个组织的两个基本战略目标——降低成本、增加收入，改变要可以实现二者之一。
在一篇2008年的文章中, Scott Ambler点明了提出成本问题背后的动机， 并指出多个来源，展示出：
敏捷方法比传统技术更为成功。
敏捷团队比传统团队更为高效。
敏捷项目比传统方法开发的产品质量更高。
敏捷项目的产出能让业务干系人更加满意。
敏捷项目比传统开发项目成本更低。
Ambler还提供了原始数据，这些数据引用自另一篇文章。
在LinkedIn的Agile Alliance 讨论组中有一篇很长的帖子谈到了该话题，并提出了一些观点：
很多时候，要度量知识工作者的工作效率是很困难的。
因为不可能将同一个项目在不同的方法论指导下完全做两次，所以要想做比较基本上是不可能的。
尽早反馈的价值，经常体现在没有犯错而节省的成本中。
敏捷项目会鼓励创新，从而产生能更好满足业务需求的产品，同时“将竞争对手远远抛在后面”。
Steve Gordon在讨论中指出：
在呼唤度量行为的背后，人们其实担心这样一个问题：以敏捷方式工作的知识工作者，他们的行为种类变化多样，很有可能不受控制。
人们可以指望敏捷来推动更快、更早的需求改进活动，这在传统的方式中很难做到（原因在于敏捷可以让人们对工作产出［working artifact］做出尽快、尽早的反馈，而且愿意做出改变）。改进需求，就能改进产出的东西。
仅仅度量原始的工作效率，这就完全丧失了上面提到的敏捷的重要效应。即使原始的工作效率数据有所下降（特别是在转换期），如果因为频繁而具体的反馈，使得产出的东西更能发挥作用，更贴近产品目标，那么交付给客户的价值就很有可能大大增加。
不过接下来的问题就是：如何度量交付给客户的价值呢？我想你的客户对此的了解要远胜于其他人。这也要看市场的情况。在真正的垄断市场中，交付的数量也许要比产品是否合适或质量更重要。在另一些市场中，创新会让你把竞争对手远远落在后面，而不光是在性能对比表格上打打勾什么的。
有意思的是，CNN将敏捷看做对软件开发管理层面的影响，并在《影响未来商业世界的50个人、产品、趋势和想法》这篇文章中进行了报道：
敏捷团队行动非常迅速，他们创建很小块的代码，工作周期有时甚至只有一周时间。完成某个组件后，就会添加新功能，这个过程会一直重复下去。敏捷在帮助管理层按时按预算交付产品方面也享有盛名，这也解释了为什么像Google和洛克希德•马丁这样的公司会选它作为方法论。
这样的宣传和支持，是否有利于敏捷实践在商业世界中推广和实施呢？