上世纪70年代，温斯顿·罗伊斯（Winston Royce）借鉴传统工业生产的预设性方法提出了一种软件开发模式：将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六项基本活动；规定了它们自上而下、相互衔接的固定次序，项目必须严格遵循预先计划的顺序进行，开发进程只有通过上一个阶段的验收审核，才能“流动”到下一个阶段。这种模式如同瀑布流水，逐级下落，故而得名**“瀑布模式（Waterfall Model）”**。
对于项目管理来说，瀑布模式具有阶段划分清晰、让开发人员在特定阶段专注于某项工作、适合向利益相关方汇报进度等特点，因此曾被软件行业广泛采用。然而随着软件行业的发展，人们也开始注意到了瀑布模式带来的问题：
- 早期阶段产生的错误（如对需求理解偏差）要等到后期测试阶段或当用户见到成果时才能被发现，进而带来严重后果；
- 开发过程一般不能逆转，如果不得不返工则会产生极大的代价；
- 基于无效假设或不明确的优先级提出的需求会让项目范围无限扩大，从而导致项目超出预算或交付延迟；
- 项目严格规定了各个阶段的输入、输出，需要开发人员投入大量精力在文档制作上面；
- ……
瀑布模式的假设是，需求能够在初始阶段被完整地捕捉和加以分析，从而制定出项目后面各阶段的详细计划。然而事实上，在软件开发的初期就要求做出正确、全面而完整的需求分析对于许多产品来说太过理想化了，一方面用户可能并不完全清楚他们需要什么，产品需求存在大量未知；另一方面即使需求足够明确，经过漫长的开发周期，需求也可能随着环境的变化而发生改变。加之开发人员必须在时间节点和里程碑的强制要求下完成工作，一旦开发成果不符合用户预期，或者在开发中途变更需求，开发人员将背负巨大压力。
在这种背景下，敏捷软件开发方法便应运而生了。较之瀑布模式，敏捷是“适应性的”，而非“预设性的”，主要体现在：
首先，敏捷欢迎变化，接受客观存在的未知和不确定，将软件开发视为适应变化的过程。 敏捷开发团队采取高频迭代的方式，不再将项目划分为只能线性推进的若干阶段，而是基于整体目标将项目分解为多个尺寸较小的“小项目”，每部分能够在远比瀑布模式短得多的周期内，快速而独立地走完计划、设计、构建、测试、发布的过程。这样一方面可持续为终端用户交付有增量感的产品，另一方面也可避免瀑布模式难以“回头”的窘境。随着产品由简入繁，之前不够清晰明确的需求会不断清晰明确，而未知的需求也会逐渐显现出来。
其次，敏捷不再像瀑布模式那样“黑箱”操作，让用户等着见到一个“全部完成”的产品之后，才能判断是否符合预期。敏捷从最重要、最明确、能够开发完成并达到使用标准的少量需求开始迭代，尽早把可用的产品交给用户，让用户加入产品开发过程，和开发团队一道确定每个迭代最主要的任务，并根据产品使用的实际体验给予反馈。如此，敏捷能将需求错位的风险降到很低，同时又能让产品在正确的方向上不断完善。
再次，敏捷更强调团队协作，而非固化的各司其职。在传统的软件开发项目中，项目团队的每位成员被视为资源，分配给特定的角色和工作，开发过程没到自己负责的环节时不需要介入。这样容易造成开发人员各自对项目需求有不同的理解却得不到有效和充分的沟通，由此产生的问题在开发后期阶段才能被发现。而敏捷则是建立一个技能重叠、持续互动、信息高度共享的项目团队，这样既使每位开发者在任一时间都有任务，无须等待前置环节而闲置人力，又能让这个团队对产品需求和开发进度的理解保持一致，避免信息不对称所带来的隐患。
最后，敏捷是“以人为本”的，更注重开发者在产品开发中的重要性，而非依靠流程来保证产品开发的质量和效率。敏捷认为“自组织”是提升团队成员彼此间的信任和自适应能力的有效途径。“自组织”形成的开发团队可以自己决定如何完成工作，并伴随开发过程在实践中不断反思、优化，探索最适合团队、最能发挥成员特点和自主性的工作方式。也就是说，敏捷开发团队本身就是迭代内容的一部分，只有使团队自身不断适配外部变化，才能让产品跟随变化为用户创造更大价值。
如今，越来越多的企业不再单纯地将敏捷看作是一种软件开发方法，而是整个企业应对这个“VUCA时代”（Volatility 易变，Uncertainty 不确定，Complexity 复杂，Ambiguity 模糊四种时代特征的概括）所能借鉴的一种思路。这种思路一方面可在软件开发上助力企业的数字化转型，另一方面也指引着组织管理和商业上的敏捷化演进 —— 敏捷，正在被视为一种组织文化和竞争优势。
根据最近一次全球最大规模的敏捷调查报告（13th Annual State of Agile Report）统计显示，企业引入敏捷开发的主要动机包括加速软件交付、提高管理变革能力、提升生产力、改善业务和IT的协调性等，而应用敏捷除了能为企业带来上述预期收益以外，还能在项目的能见性、可预测性、风险和成本管控，以及团队士气等方面有所贡献。