我们买来了敏捷，却忘了改变工作方式：一次敏捷转型的复盘
一家中型机构在启动他们所谓的敏捷转型一年后找到我们。他们培训了人员、采购了工具，并把每个小组都重新命名为「Scrum团队」。然而交付速度并未加快，员工却疲惫不堪。2021年初的一次视频通话中，一位团队负责人的坦诚总结是：「我们现在开齐了所有会议，可什么都没变。」
下文经过匿名处理，并由多个项目拼合而成，但这种失败模式是Scrum落地中最常见的之一。他们照搬了Scrum的各种仪式，却没有接纳它的目的。这一点有《Scrum指南》为据——指南将Scrum描述为一个建立在经验主义之上的框架，而非一套需要走过场的会议。
徒有其名的转型有哪些症状
表面上一切都很敏捷。底下，旧有的命令与控制式习惯丝毫未动，只是换上了新词汇。
每日Scrum变成了一场汇报会，开发者向经理报告进度，而非开发者之间为自己当天工作所做的计划。
Sprint评审展示的是幻灯片而非可运行的产品，因此没有真正的反馈可以流动。
产品负责人其实无法决定优先级；一个指导委员会每月推翻产品待办列表。
Sprint先按截止日期来规划，再塞进任何能放下的范围，于是团队从第一天起就处于落后状态。
这些都是走过场的迹象。事件都排进了日程，但支撑它们的经验主义——检视真实成果并据此调整——却从未发生。由于远程和混合办公对许多人来说还很新，这些会议又成了唯一的联系渠道，让人感觉更加沉重。
是什么改变了走向
我们没有增加更多Scrum。我们让现有的Scrum真正具有意义——一次只解决一个约束，并让管理层亲临处理最棘手的部分。
赋予产品负责人真正的权限。 管理层达成一致：产品待办列表的排序权完全归产品负责人，没有例外。指导委员会转而负责设定目标和拨付资金，不再在Sprint中途重排工作。
让Sprint评审展示可运行的软件。 不再用幻灯片。干系人看到的是可运行的增量，并给出能反馈进下一个Sprint的意见。能据以行动的反馈，正是在评审中进行检视的全部意义。
让团队围绕Sprint目标而非愿望清单来规划。 每个Sprint都承诺一个清晰的单一目标，以及由团队自行选择的预测。范围会为保护目标而灵活调整，这正是Scrum应对压力的方式。
把Scrum Master重新定位为教练，而非协调员。 我们让Scrum Master不再忙于订会议室，而是去清除系统性障碍，比如那条扼住产品负责人的审批链条。
进展并不均衡，一些经理难以放下控制权。但在两三个季度之内，各团队开始更频繁地发布更小的增量，疲惫感也随之缓解——因为真正重要的终于是工作本身，而非仪式。
值得记住的教训
敏捷转型不是会议或工具的铺开，而是决策方式的转变，以及你从真实成果中学习的速度。只有当事件底下的经验主义是真实的，Scrum的各项事件才会创造价值。如果你的每日Scrum是一份进度汇报、评审是一叠幻灯片，那么无论日程上怎么写，你都还没有真正拥有Scrum。先让其中一个事件变得真正诚实，再让它带动其余。
如果你的敏捷转型只有仪式、却没有成果，XNM的项目与计划交付咨询服务可以帮助你把走过场的动作重新变回真实可用的敏捷力。