曾经我认为，敏捷的各种实践，只要有了标准化的动作，加上一点点定制，加上PDCA/SDCA，就能做好。迈向敏捷之路，是可以唯一定义并且重复实施的。比如说持续集成，大师说“在自己的计算机上启动一个自动化build”是重要的──我们把它叫做“本地构建”。做不好本地构建，提交构建失败率就会高，对持续集成的信心就会失去。这个问题，和它的解决方案，都是确定且可重复的。

可是这个团队让我吃惊了。他们一直没有真正意义上的本地构建。但他们真的相信持续集成──不仅仅是几个领导，是整个团队，真的相信：如果每天发现的小问题不能及时解决，那么到版本上线时一定会被客户骂得狗血淋头。他们不想被骂，他们也不想同一个战壕里的战友被骂，所以他们就把持续集成做好了。尽管没有真正意义上的本地构建，就靠着原始简单的代码评审，更认真的态度，他们就真的把持续集成做好了。

这个团队颠覆了一些正在我脑中渐渐成型的东西，让我想起了一些原本印象深刻但被渐渐遮掩起来的东西，比如敏捷宣言的第一条：个体与交互重于过程和工具。

面对巨大组织时强烈的无力感、无助感会让“敏捷推行人”们（包括我自己在内）不自觉地选择把自己的定位拔高──也许真是想帮助更多的人，也许只是想从残酷的现实中逃开，抑或两者兼而有之。但这些人不会做高层面的事情。于是离开低层面、离开具体事务的结果就是不知道该做什么，就是把敏捷推行简化为过程和工具的推行。

有一个敏捷推行人对我说，我负责几十个项目的改进，如果每次只到一个项目去做具体的事，对整体的帮助很小。我对她说，也许你救不了所有的鱼，但被你救的这一条鱼，它会在乎，它会得救。在反复思考如何拯救所有鱼的过程中，其实你什么也没有做，没有一条鱼真的得救。

敏捷的改变，最终是一个一个人的改变。过程和工具会帮助你。但如果把敏捷简化成过程和工具，你就在一步步远离敏捷，因为你已经违背了敏捷宣言的第一条原则。