全球知名IT研究公司Gartner 研究表明，到2012年底，敏捷开发方法将占软件开发项目的80%。 PMI推出了敏捷管理专业人士认证（PMI AgileCertified Practitioner（ACPsm）），以培养更多的敏捷管理人才。关于敏捷方法和传统瀑布方法的偏见
对于敏捷方法和传统瀑布方法一直以来都有很多误解：
走向敏捷就是革了官僚体系和瀑布式流程的命。从事敏捷工作的人努力地与这些东西划清界限。于是所谓的迁移就是走向与传统瀑布模型完全相反的方向（只有很少的甚至是没有文档、流程和操作方法等）。
那些采用传统瀑布模型的公司则走向另一个极端，它们顽固地坚持以控制为导向，强调对成本和时间的精确估计和严格管理。若要以精确的管理成本和时间作为目标，优秀的项目经理都知道他们必须控制用户需求和项目范围的变化。如此也就不难理解，这部分人难以接受敏捷方法中对变化的那种高灵活性和容忍度。
2003年，巴里·波姆（Barry Boehm）和理查德·图纳（Richard Turner）提到：
“不幸的是，这两种方法没有选择互相补充、求同存异，而是把对方当作敌人，把这看作一个零和游戏。敏捷支持者攻击传统方法‘卫道士’过分崇拜流程，不够人性化的软件开发方法，而‘卫道士’们则指责敏捷方法容易导致项目失控，质量低下，以及不够严谨。两个阵营的坚定支持者们大肆鼓吹他们的信念，就好像他们是上帝派来的使者，这使得那些想要改进开发策略的软件开发者和项目经理越加迷惑了。”
在那之后，这两种论点都有一些新的发展，但是在很多情况下人们还是认为它们是大相径庭的。
敏捷方法已经越来越成熟。类似Scrum的方法现在已经不仅是一个开发流程，其背后有着强大的理论和实践的支撑。但在很多人的脑海中，敏捷方法仍然是一个不严谨的开发流程。
有很多人采用了新的方法使传统开发模式变得更加灵活，让文档和流程变得更有意义，并越来越多地采用了迭代开发模式来平衡项目的灵活性和控制性。但这没有改变很多人始终认为的传统开发方法就意味着独断和官僚。
现在是到了找到一个中间地带的时候了，我们需要在两者的鸿沟间建起一座桥梁，其实大部分的差异不是真实存在的，而是由人们的偏见造成的。在很多情况下，理解如何实施这些方法比理解方法本身更加重要。
想要建立一个切实可行的企业整体战略，需要更深入地了解这两个领域；想要建立一个更大的知识体系，需要掌握跨越敏捷和传统模式的很多方法论、实践和原理。对于所有的组织机构来讲，选择合适的方法或多个方法的组合都是非常关键的战略决策。所选择的方法必须跟企业的业务战略、企业文化、所处商业环境及特定项目所面临的风险和项目复杂程度协调一致。例如：
在一个高风险的行业或应用领域，必须要相应地提前计划，只有这样才能保证对潜在风险的预测并建立起风险应对机制。
而在一个高度管制的领域，必须编写规范的文档来描述项目需求、测试计划和测试结果等，以满足政策上的要求。
在以上的各种情况中，需要找到控制和灵活之间的平衡以满足这些要求。而现实中有很多方法不需要完全放弃控制性，也可以获得一定的灵活性。选择合适的方法要由业务部门和开发部门共同完成，需要了解各种可选方案的优缺点。刻板地套用教科书上的标准方法（不管是敏捷的还是传统的），而不针对具体业务情况做出调整很难获得成功。另外，最佳方案有可能不是某个单独的方法而是根据每个项目的具体需求量身定做的多个方法的组合方案。
1.4 盲目跟风现象
任何新的方法，当它是个大热门的时候，都有可能造成盲目