一项研究发现，采用敏捷实践的项目失败的可能性比不采用敏捷实践的项目高268%.
尽管由咨询公司EngPrax委托进行的这项研究可能被视为对影响工程方法论的几乎不加掩饰的宣传，但它加剧了人们的怀疑，即敏捷宣言可能并不像它所吹嘘的那样.
该研究的实地调查是在5月3日至5月7日之间进行的，有600名软件工程师(英国250名，美国350名)参与.
一个突出的统计数据是，在开发开始之前记录了明确需求的项目成功的可能性要高出97%.
相比之下，敏捷宣言的四大支柱之一是“工作软件重于全面文档”.
根据这项研究，在开发开始之前制定规范可以使成功率增加50%，确保需求与现实世界的问题准确可以导致57%的增加.
《影响工程》的作者Junade Ali博士说：“65%的采用敏捷实践的项目未能按时交付，是时候质疑敏捷的狂热追随者了.
我们的研究表明，当涉及到按时并在预算内交付高质量软件时，重要的是强大的需求工程过程，以及在出现问题时拥有讨论和解决问题的心理安全感，同时采取措施防止开发人员精疲力竭.
敏捷宣言多年来一直受到批评.
臭名昭著的英国邮局地平线IT系统是使用该方法的早期大型项目，尽管将该系统的设计缺陷归咎于敏捷方法似乎有点牵强.
此外，人们也很容易忘记，其他方法也有自己的缺陷.
例如，瀑布使用了一系列文档化的阶段，而编码只是其中的一部分.
虽然瀑布很容易理解和管理，但它也可能很慢，成本也很高，实施变化具有挑战性.
因此，团队有寻找替代方案的趋势.
在工程师认为他们可以自由讨论和解决问题的项目中，成功的可能性高出87%.
根据这项研究，令人担忧的是，英国的员工认为他们可以讨论问题的可能性比美国人低13%.
当今科技世界的许多罪过往往被归因于《敏捷宣言》.
源源不断的补丁表明，质量可能不再是过去的样子了，出现在未完成或考虑不周的状态的代码都被归因于敏捷实践.
一位敏捷开发人员批评了每日单口相声元素，将其描述为向注册中心提交的“反胃盛宴”.
然而，尽管敏捷宣言可能存在问题，但这些问题更多地源于其实现，而不是原则本身.
“我们不需要测试团队，因为我们是敏捷的”，这是一种节省成本的责任放弃.
在强调在开发开始之前理解需求的必要性方面，这项研究描绘了敏捷纯粹主义者和瀑布倡导者之间的一条道路.®.