一家互联网企业A开展敏捷转型时，曾走过这样一段弯路。首席技术官（CTO）听闻敏捷很流行，可以提升研发效率，意识到这是一个趋势。更为关键的是，友商在做敏捷！迫于竞争的压力，于是CTO下令：“搞敏捷！”

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

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

接下来，在任命了ScrumMaster和产品负责人（ProductOwner，简称PO）后，试点部门的几个团队变成了“Scrum团队”。PMO为了固化敏捷，制作了检查表，监督团队每天开站会，以及每个Sprint都召开了计划会议和评审会议。在检查表中，开了这些会的团队打“√”，没开的打“×”，PMO定期将检查表上报给CTO。

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

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

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

而当我深入团队后发现，没有一个团队对敏捷的理解是正确而又深入的，大家的敏捷实践还都只停留在简单的召开Scrum会议的层面。这家公司的问题可以归纳为如下几个方面。

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

其次是团队的角色划分问题。虽然每个团队都任命了ScrumMaster和产品负责人，但是团队仍然保持着传统项目经理式的管控方式，完全没有自组织，ScrumMaster也不知道自己与项目经理有什么区别。产品负责人不是来自于业务团队，而是由研发部门的业务分析员担任。

产品负责人并没有与业务团队、用户密切合作，而仍旧是关起门来自己创造并分析需求。

最后是Scrum里常见的几个会议问题。在每日站会上，团队成员给ScrumMaster汇报自己的工作状态，ScrumMaster则负责给每个人安排任务——今天该做什么，怎么做。在迭代计划（SprintPlanning）会议上，团队将用户故事拆分为前台开发、后台开发、架构设计、代码评审等任务；在Sprint评审会议上，ScrumMaster使用幻灯片来对团队的迭代工作进行总结，包括完成了哪些用户故事，解决了哪些Bug。在Sprint的回顾会议上，鲜有团队成员发言，多数情况都是在ScrumMaster安排好任务后便草草结束。

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

这是一个在业界非常典型而且普遍发生的转型失败案例，我将其总结为“船货膜拜”（CargoCult），即肤浅地应用实践，但没有深入理解敏捷原则和实践的意图，因而也就没有达到敏捷应有的效果。

令人惊讶的是，很多企业都在做这种船货膜拜式敏捷：

• 每天召开站会，但却没有进行密切协作和自组织；
• 每个迭代都有计划会议和评审会议，但在迭代结束时没有可交付的产品增量；
• 每个迭代都有回顾会议，但团队的流程、效率质量、协作等却没有实质的改进；
• 各种Scrum角色也都存在，但没有行使Scrum赋予他们的职能；
• 开展的各种工程实践属于应付差事，没有起到实质性作用。
  

因此，敏捷转型不是一件说做就做、照猫画虎的事情。相反，它是一场艰巨的变革运动。

一家互联网企业A开展敏捷转型时，曾走过这样一段弯路。首席技术官（CTO）听闻敏捷很流行，可以提升研发效率，意识到这是一个趋势。更为关键的是，友商在做敏捷！迫于竞争的压力，于是CTO下令：“搞敏捷！”

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

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

接下来，在任命了ScrumMaster和产品负责人（ProductOwner，简称PO）后，试点部门的几个团队变成了“Scrum团队”。PMO为了固化敏捷，制作了检查表，监督团队每天开站会，以及每个Sprint都召开了计划会议和评审会议。在检查表中，开了这些会的团队打“√”，没开的打“×”，PMO定期将检查表上报给CTO。

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

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

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

而当我深入团队后发现，没有一个团队对敏捷的理解是正确而又深入的，大家的敏捷实践还都只停留在简单的召开Scrum会议的层面。这家公司的问题可以归纳为如下几个方面。

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

其次是团队的角色划分问题。虽然每个团队都任命了ScrumMaster和产品负责人，但是团队仍然保持着传统项目经理式的管控方式，完全没有自组织，ScrumMaster也不知道自己与项目经理有什么区别。产品负责人不是来自于业务团队，而是由研发部门的业务分析员担任。

产品负责人并没有与业务团队、用户密切合作，而仍旧是关起门来自己创造并分析需求。

最后是Scrum里常见的几个会议问题。在每日站会上，团队成员给ScrumMaster汇报自己的工作状态，ScrumMaster则负责给每个人安排任务——今天该做什么，怎么做。在迭代计划（SprintPlanning）会议上，团队将用户故事拆分为前台开发、后台开发、架构设计、代码评审等任务；在Sprint评审会议上，ScrumMaster使用幻灯片来对团队的迭代工作进行总结，包括完成了哪些用户故事，解决了哪些Bug。在Sprint的回顾会议上，鲜有团队成员发言，多数情况都是在ScrumMaster安排好任务后便草草结束。

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

这是一个在业界非常典型而且普遍发生的转型失败案例，我将其总结为“船货膜拜”（CargoCult），即肤浅地应用实践，但没有深入理解敏捷原则和实践的意图，因而也就没有达到敏捷应有的效果。

令人惊讶的是，很多企业都在做这种船货膜拜式敏捷：

• 每天召开站会，但却没有进行密切协作和自组织；
• 每个迭代都有计划会议和评审会议，但在迭代结束时没有可交付的产品增量；
• 每个迭代都有回顾会议，但团队的流程、效率质量、协作等却没有实质的改进；
• 各种Scrum角色也都存在，但没有行使Scrum赋予他们的职能；
• 开展的各种工程实践属于应付差事，没有起到实质性作用。
  

因此，敏捷转型不是一件说做就做、照猫画虎的事情。相反，它是一场艰巨的变革运动。