这可能是因为有这么几个门槛。
第一道门槛是，每个人都要熟悉敏捷。
正像前篇所说的那样，拉一堆不熟悉敏捷的人去按照敏捷流程做事情，由于这些人只是按照敏捷的形式去做，而不清楚敏捷解决了什么问题，不清楚为什么要用敏捷，就可能会导致应用敏捷的效果适得其反。比如站立晨会，如果大家认为它只是一个向boss汇报工作的过程，就很可能会成为一个非常鸡肋的环节了。
类似的情况可能还会发生在敏捷的一些实践上，比如“简单的设计”，如果曲解了这个实践的含义，可能会造成对设计要求的降低，当我们滥用这个原则去拒绝一些可以预见的复杂需求的时候，我们可能不得不在下一个迭代推翻很多老的设计。
第二道门槛是，敏捷容易“水土不服”。
敏捷是思想，把它应用好需要一定的时间和经验。就好比 马 克 思 主义进中国一样，一定要适应于“中国特色”之后，才能被用好。Mary Poppendieck和Jean Tabaka在敏捷大会上都指出了，敏捷开发并不是件容易的事情，短时间内很难做到，而且这需要不断地改变过去。
举个例子，敏捷实践中有结对编程，Laurie Williams和Nosek的研究表明，结对非但不会降低开发团队的效率，而且会大大减少缺陷率。但应用到实际的项目和团队中，这个效果又会怎样呢？一些分析表明（项目总结－结对编程，http://www.soft6.com/tech/6/63739.html），这其中是存在一定的障碍的，比如老员工习惯单打独斗，性格问题，经验差距过大，企业文化等问题。结对之前首先要克服这些问题，才能达到比较好的效果。
再举个常见的例子，敏捷要求，在整个项目开发期间，业务人员和开发人员必须天天都在一起工作，可是这在许多大型公司的部门架构中，是不现实的。同样，对于甲方乙方公司，以及客户是看不见的网民的互联网公司，这个要求也多少有些严格了。
第三个门槛是，坚持敏捷很难。
我们会尝试很多敏捷的实践，我们会努力去改变一些过去的行为，这个过程可能会花很多时间。
每个人都会有自己的惯性思维，也会有自己习惯的工作方式。改变的过程不会是一瞬间的，在这个过程中，会有一定的状态起伏，甚至状态下降也说不定。如果在这个过程中因为效果不好而放弃，或者没有形成新的习惯，从而回到了老的习惯，那么就可能不会再去迈出改变的第二步。
另外就是，敏捷的一些实践（比如持续集成，自动化测试）是需要构建一些基础设施出来的，面对遗留系统，这可能会是个大成本的事情。
还有其它情况，比如进度压力太大的时候，敏捷的队形会被扭曲（敏捷之收获http://blog.tianya.cn/blogger/post_show.asp?BlogID=169274&PostID=16474714），在找到真正适合自己的敏捷实践之前，我们是否有毅力坚持下去？
还有很多其它的门槛。
我认为，很多时候，使用敏捷之所以没有获得预期的效果，主要还是在于使用方法上。敏捷的核心在于以人为本，由于人是活的，所以人既有可能做得很差，也可能做出非凡的成绩，关键在于是否找到了适合自己和团队的实践方法来。这肯定不是一朝一夕的事情。我认为，只要大家的目标是一致的，坚信敏捷是对的，那么就坚持下去，不要中途放弃，相信这样久了，就一定能找到适合的实践方法的。