我待过三个号称用Scrum的团队，每个团队的Sprint board上都贴满了便签，站会准时，回顾会积极发言，可交付物就是不能看。后来我发现，我们所有人的精力都消耗在了把任务描述得足够模糊，好让验收标准永远无法被精准测量。大家不是在用Scrum，是在玩一个叫Scrum的剧本杀——产品经理扮演客户，开发扮演资源，Scrum Master扮演主持人。剧本的结局早已写好：Sprint结束，演示功能，全员鼓掌，然后进入下一个循环。
但Scrum的本意不是这样的。读《Scrum Guide》时有一句至关重要的话往往被忽略——Scrum是轻量的、易于理解的，但难以精通。而这“难以精通”的根源在于，Scrum强制我们面对不确定性。站会上的三个问题，不是为了同步进度，而是为了当场暴露矛盾，让研发和产品陷入一场也许没有答案的对话。可是大多数团队只想要一个确定的计划，他们受不了这种持续两周的不安感。于是我们发明了“story point扑克”，把复杂性变成数字，把数字除以速率，算出所谓的“承诺”。这个操作实际上背叛了Scrum的基本前提，我们用手忙脚乱的估算游戏替代了对不确定性的恐惧。
我对比过传统瀑布和Scrum在同一个项目上的表现，结果很有意思。瀑布至少诚实地承认“前期设计不够”这件事，但Scrum的迭代设计却常常变成“永远设计不完整”。瀑布的文档再烂，好歹有一个唯一的版本；而Scrum的backlog里全是互相矛盾的待办项，因为没人愿意在梳理会上做真正的决策。我更相信，Scrum是一种压力测试器，它暴露的是组织里权力的真实分布。自组织团队？那是幻想。在一个部门墙林立、绩效考评按个人工作量计算的公司里，所谓自组织不过是把原来项目经理做的派活任务，内部转移给了几个最容易焦虑的成员。他们用Scrum的语言重新包装了等级制度，称之为“角色”。
有一次我在回顾会上问了一个不该问的问题：“如果我们可以不延续当前的Sprint节奏，你们最想改变什么？”空气静了几秒，产品经理说“我觉得Sprint太短了，很多功能来不及完成”，开发说“我感觉我们对技术债的定义始终不一致”，而Scrum Master说“可以，我们列为待办”。那一刻我意识到，Scrum的仪式感已经在团队内形成了某种“安全沉默”——所有冲突都被装进待办列表，等待某个永远不会到来的Sprint。如果真要给个建议，我会说：停止用Scrum作为效率工具，把它当成一面镜子。你在Sprint中看到的拖延、争功、伪装承诺、互相扯皮，就是你所在组织的真实文化和权力结构。你真正要修的，不是燃烧图，而是你的组织运作方式。否则，换框架，Kanban、XP、或者随便什么名字，都是一样的壳。
很多敏捷教练喜欢引用爱因斯坦的定义“疯狂就是重复做同一件事而期待不同结果”。我不指望这句话能拯救谁。但我想起自己第一次做Scrum时，我们被要求不要用“我完成”而要说“我们完成”。后来一位老工程师嗤笑一声——他说，真到查代码的时候，谁写的谁心里有数。他这话不无道理，但在这个虚构的“我们”背后，我曾经见过一个开发为了帮新人修bug而连续两天加班到凌晨，并且没有把这件事记上燃尽图。那才是Scrum里最像幽灵的时刻——不是僵硬的仪式，而是一个活人在庞大流程夹缝里笨拙地对同事履行着真实的承诺。这种牺牲不合规，也传染不了，但它让我觉得，Scrum的躯体里偶尔住着某个值得留下的灵魂。而我们真正该做的，是让那个灵魂获得更多的生存空间，而不是继续打磨那副漂亮的骨架。
