敏捷转型是场艰巨的运动-失败案例：船货膜拜

某互联网企业开展敏捷转型走过这样一段弯路。CTO听闻敏捷这玩意儿很流行，意识到是个趋势，据说可以提升研发效率，更为关键的是：友商在做敏捷！这可不得了，不能让友商超过咱们。就这样，CTO下令：“搞敏捷！”

领导说搞就搞呗，为什么搞？怎么搞？谁知道呢？！领导日理万机，怎么可能亲自抓？于是，CTO安排PMO（Project Management Office: 项目管理办公室）专门负责敏捷专项工作，目标只有一个：通过敏捷来提升研发效率。

PMO得到这个差事之后很有热情，正愁没有抓手驱动组织改进，这是个千载难逢的好机会。不过，总得先知道敏捷是个啥才能搞吧？于是，PMO安排专人去参加了Scrum公开课。培训归来，PMO召集各部门主管，花了2个多小时，介绍了敏捷是个啥东西，宣传了领导的愿景：通过敏捷来提升效率，要求大家积极响应。部门主管们一头雾水，没人愿意拿自己的团队做实验。但是，这个事情得继续推进啊，于是，PMO在领导的支持下，派了一个部门开始试点。

接下来，试点部门的几个团队分别任命了Scrum Master和产品负责人（Product Owner，简称PO），变成了“Scrum团队”。PMO为了固化敏捷，制作了个检查表，监督团队每天开站会，每个Sprint召开了计划会议和评审会议。开了这些会的团队打对勾，没开的打×，定期上报CTO。

就这样，试点部门的团队们开始了他们的“敏捷”之旅。懵懵懂懂地，几个团队坚持“敏捷”三个月了。PMO对团队进行了访谈：效果咋样？团队纷纷反馈，每天对着任务板沟通，协作效率感觉提升了。

CTO听取了PMO的汇报，加之对提高研发效率的渴望，立即决定：在公司范围内全面推广敏捷。于是，在试点团队还没有完全理解Scrum，并且没有定量数据证明改进效果的情况下，Scrum就仓促地大范围铺开了。领导说做就做呗，一夜之间，产生了大量的Scrum Master和PO。PMO的童鞋则忙的不可开交，因为有太多的团队需要指导、检查和监督。

当我应邀去这家企业提供顾问服务的时候，发现该企业处于如下状况：整个公司做了整整一年敏捷，不仅在数据上没有证明有效地提升了研发效率，而且从主观感受上也没有什么明显的效果。于是，很多部门主管开始抵制敏捷。CTO向我抱怨道：“说实话，我的心里也开始怀疑敏捷了，这大大低于我们的预期 啊！”

而当我深入到团队中后，发现没有一个团队对敏捷的理解是正确且深入的，大家的敏捷实践还都只停留在简单的召开Scrum会议的层面。

首先来看看团队的组织结构。

虽然每个团队都被称作Scrum团队，但仍旧是职能团队，即前台团队、后台团队、底层驱动团队等按照工作职能进行划分的结构。在组织架构没有组建特性团队，很多部门主管不知道敏捷团队的组织架构应该是什么样子，即使个别有些了解的主管认为，那样的架构不符合组织的现实情况，不应该也不需要调整。

其次，团队的角色划分问题。

虽然每个团队都任命了Scrum Master和产品负责人，但是团队仍然保持着传统项目经理式的管控方式，完全没有自组织，Scrum Master也不知道自己与项目经理有什么区别。产品负责人不是来自于业务团队，而是由原来的BA（Business Analytics, 业务分析员）改了个Title。即便算是个代理产品负责人，也没有与业务团队、用户密切合作，仍旧是关起门来自己创造并分析需求。

最后，即便是Scrum里常见的几个会议，很多团队也是这样召开的：

团队成员在每日站会上给Scrum Master汇报自己的工作状态，Scrum Master则负责给每个人安排任务 - 今天该做什么，怎么做；在Sprint Planning会议上，团队将用户故事拆分为前台开发、后台开发、架构设计、代码评审等等任务；

Scrum Master在Sprint 评审会议上只是使用了一个幻灯片来对团队本迭代的工作进行了总结，完成了哪些Story, 解决了哪些Bug；Sprint的回顾会议上，鲜有团队成员发言，多数情况都是在Scrum Master安排的任务中草草结束；

除此之外，个别的团队开展了一些零星的工程实践，例如“有空做，没空不做的”持续集成、自动化测试等等。

这是一个在业界非常典型而且普遍发生的转型失败案例，我将之总结为船货膜拜（Cargo Cult）[1]，即：肤浅地应用实践，但不深入理解原则和实践的意图，从而没有达到敏捷应该起到的效果。

Cargo cult science(船货膜拜)由Richard P. Feynman提出，指的是那些浮于科学调查和研究的表面形式，却丧失科学本质的伪科学。

令人惊讶的是，在很多企业里在做这样的船货膜拜式敏捷，例如：