软件开发过程中，最大的挑战之一就是确保开发的软件真正解决了客户的问题。敏捷宣言的诞生部分就是为了解决这个问题。敏捷宣言的第一个指导原则是：“最高优先级是通过早期和持续交付有价值的软件来满足客户。”
敏捷宣言是由一群软件开发者在1991年2月在犹他州会面两天后制定的。它的内容如下：
通过实践和帮助他人实践，发现了更好的软件开发方式。通过这项工作，开始重视：
- 个体和互动高于流程和工具
- 可工作的软件高于详尽的文档
- 客户合作高于合同谈判
- 对变化的响应高于遵循计划
也就是说，尽管右边的项目也有价值，但更重视左边的项目。
尽管敏捷宣言和其背后的原理对软件开发实践没有具体规定，但大多数人会同意，敏捷软件开发团队或过程有两个标志：
如果真正遵循这两个原则，很可能会交付客户真正想要使用的软件。
当一个组织开始变得“敏捷”时，他们很容易养成频繁向客户交付软件的习惯。不幸的是，客户合作要难得多，这也是本文剩余部分的主题。
如果是软件开发者，可能听说过Scrum方法论。可以在Wikipedia上找到简要描述，以及在JeffSutherland.com/ScrumPapers.pdf上找到更详细的文档。简而言之，Scrum涉及团队在称为冲刺或迭代的增量周期内交付软件。Scrum团队由产品负责人、Scrum主管和团队成员组成。产品负责人被称为客户的代言人，在计划会议上代表客户。
许多人将Scrum等同于敏捷，其创造者也大力推广它作为一种敏捷软件开发过程。可能令人惊讶的是，可以完全按照Scrum方法论来执行，而完全忽视实际客户！
在Scrum方法论中，客户可能参与的唯一时刻是在冲刺评审期间，但这并不是强制性的。理论上，让产品负责人（通常是产品设计师、产品经理或软件开发者）作为客户的代理人是足够的。问题是，他们并不是真正的客户。他们有自己的偏见和议程，并不一定符合客户的愿望或需求。
并不是说Scrum是一种糟糕的软件开发方法论，或者产品负责人毫无意义。是说，为了避免创建一个YAGNI（不需要它）的功能，必须在迭代过程中直接与客户合作。
敏捷不仅仅是一个流行词；它代表了商业软件开发的一系列理想目标和原则。