2013 年 9 月，英国议会公共账目委员会的一位委员，想把「统一福利」的遭遇总结一下。这是英国把六种福利合为一种的计划。福利部门用「敏捷」方法来建这套系统，而这种方法「从来没有在这么大的规模上用过」。他听说，现在项目又退回了老办法。「实际上，他们是推倒重来了。」
政府重大项目管理局的代理总干事也在场作证。她说，项目现在一部分用敏捷，一部分用传统方法，而这并不是要害。「问题不在方法，而在用这些方法时有多严谨、多有章法。」其余经过见案例。
四条偏好
能用的成果和当面沟通，优先于文档和死计划，但两边都要留着。
2001 年 2 月，十七位软件开发者聚在犹他州的一家滑雪旅馆。他们来自彼此竞争的不同流派，有极限编程、Scrum、DSDM 等等，最后在四句话上达成了一致：
- 个体和互动高于流程和工具
- 能用的软件高于详尽的文档
- 与客户合作高于合同谈判
- 响应变化高于遵循计划
「也就是说，」他们接着写道，「尽管右边各项也有价值，我们更看重左边各项。」这句话很容易被跳过，分量却全在这里。宣言没有扔掉计划和文档，它说的是两者打架时谁优先。作者之一吉姆·海史密斯写道，这群人「并不反对方法论」，而是想「恢复一种平衡」。
宣言还附了十二条原则。这里最要紧的是两条：「能用的软件是衡量进度的首要标准」；「简单，也就是尽量少做不必要的工作的艺术，是根本」。
只有名字，没有取舍
统一福利用上了这个名字。英国国家审计署发现，该部在 2010 年底选定敏捷，是为了能在政策定稿之前就开建。拿四条偏好去对照审计结论，大致是这样：
- 个体和互动：项目膨胀到一千多人，用的却是「通常用于小型协作团队的方法」。
- 能用的软件：项目委员会看得到各项活动的数字，却「无法对照支出，追踪这些活动的实际价值」。
- 与客户合作：普华永道的审查发现，供应商按工时和材料收费，交付物「并不总是在签合同前就定清楚」，审查认为这让大部分风险落在了该部头上。
- 响应变化：该部坚持在 2013 年 10 月全国推行，却向审计人员解释不出为什么定这个日子；到了 2013 年，它放弃了这个日期。
据审计署报告，内阁办公室认为，在重启之前，该部「任何时候都没有恰当地采用过敏捷方法」。之后，该部开始自己组建团队、继续用敏捷方法开发一套新的数字服务。2014 年 9 月，这套服务通过了政府的第一阶段审核，证明已经做出能用的原型，只是因为招人困难，比计划晚了六个月。
设想一家五个人的活动策划公司，开始每天开站会，自称敏捷。如果客户照旧在一月份签下一张定死的清单，一直到六月活动当天才看到成果，那这些会也许改变了一周的感觉，却没有改变客户拿到的东西。
AI 时代的敏捷
宣言是为软件团队写的，但它偏爱简单、能用的东西，这一点可以搬到用 AI 做事上。Anthropic 在 2024 年的一份指南里写道，在它合作过的几十个开发 AI 智能体的团队里，「最成功的做法，用的不是复杂的框架或专门的库，而是简单、可组合的模式」。它的建议是：「只有在能明显改善结果时，才考虑增加复杂度。」这很接近宣言里的「简单」原则，也接近它衡量进度的标准：东西能不能用。
这种迁移有边界。智能体不是可以合作的客户，框架也不是官僚体系。能搬过来的，是一个习惯：常问一问，某个流程或工具是在让活干得更好，还是只让它看起来更有条理。
2013 年，英国这个 22 亿英镑的福利项目挂着「敏捷」二字。按审计人员的说法，这两个字代表的东西，它当时还没用上。