先给结论。按照 2020 版 Scrum 指南，Scrum Master 负责两件事：按指南的定义把 Scrum 建立起来，以及 Scrum 团队的效能。具体来说，就是为开发人员、产品负责人（Product Owner）和整个组织服务：辅导团队学会自我管理，推动清除阻碍进展的障碍，确保各项 Scrum 事件如期举行、开得有成效，并且不超出时间盒（timebox）。至于给人分派任务、催团队交结果，指南里从来没要求 Scrum Master 做。这篇想聊的，就是这中间的差别。
我经历过的最糟糕的几次回顾会，长得一模一样：Sprint 目标没达成，于是整整一小时变成"为什么没完成"的审讯大会。而最好的几次回顾会，几乎没怎么提目标本身。我们聊的是这段时间怎么干活的、什么东西拖了后腿、下次想换个什么做法。这个差别，就是所谓"不被结果绑架的心态"。自己带着团队跑了一段时间 Sprint 之后，我越来越觉得这是 Scrum Master 最要紧的一种素质。
先说清楚：结果当然重要。流程漂亮但什么都发不出去的团队，没人会发工资。但是，完成 Sprint 是团队的活儿；Scrum Master 的活儿是改进那台"产出 Sprint 的机器"。这是两份不同的工作，我见过的 Scrum 乱象，大多是从把这两件事搅在一起开始的。
Scrum Master 和项目经理有什么区别#
这两个角色经常被混为一谈，部分原因是不少公司干脆让一个人兼着。核心区别是：
| Scrum Master | 项目经理 | |
|---|---|---|
| 管什么 | 团队怎么干活，干得顺不顺 | 范围、进度和预算 |
| 分派任务吗？ | 不分派，开发人员自己规划 | 通常会 |
| 成功是什么样 | 团队一个 Sprint 比一个 Sprint 好 | 项目按时、按预算交付 |
Scrum 本身没有项目经理这个角色。项目经理平时干的不少活，分到了产品负责人（决定做什么、先做什么）和开发人员（规划怎么做）身上。
放下对结果的执念之后，会变好的几件事#
首先，团队才有空间真正当家做主。Scrum 的前提本来就是自组织团队，可一个为每个结果提心吊胆的 Scrum Master，不知不觉就会把手伸进决策里。团队很快就学会了：“反正拍板的不是我们。“把重心放回流程，你才能放手让大家去实验、偶尔做错决定、再从里面学到东西。主人翁意识只能这么长出来。
回顾会也会变得诚实。当会议室里的问题是"为什么数字没达标”，真话就藏起来了；换成"什么拖慢了我们、下次试点什么”，大家才肯开口。Sprint 中途冒出来的障碍也一样：执着结果的 Scrum Master 会为交期慌了手脚，专注流程的那位则闷头去把拦路的东西清掉；如果拦路的是一个谁都还没摸清的问题，就提议做一个限定时间的 Spike 去查清楚。
跟利益相关方的关系也会缓和许多。如果你能讲的故事只有燃尽图，那任何一点波动看起来都像失败。要是还能讲清楚团队学到了什么、怎么在调整，大家的预期就会现实得多——很多本来会在 Sprint 中途砸到团队头上的压力，你也就能在外面替他们挡掉。
如果你已经在为某个结果魂不守舍#
道理都懂，做起来难，我知道。当你在某件事上投入很深的时候，“专注过程"听起来就像冰箱贴上的鸡汤。
说几个对我真正有用的办法。第一，别为"在乎结果"责怪自己——想要一个结果是人之常情，装作不在乎撑不了多久。第二，把结果目标翻译成你能控制的过程目标：不是"赢下这场比赛”，而是"每天练 30 分钟"。发布受不受欢迎你控制不了，但有没有做过评审、跑过测试、提前演示过，你控制得了。第三，看清是什么在给执念添柴。要是你一天刷十遍仪表盘或者股价，就定好固定的查看时间，其余时间不看。路上的小胜利也要记得庆祝，不然远处那个大目标会把你的注意力吃得干干净净。如果这种执念已经严重到影响睡眠和日常生活，去找专业人士聊聊很值得，一点也不丢人。
结果依然重要。但那些能稳定拿到结果的团队，背后总有一个人在照看"怎么做"，而不只是"做出了什么"。