不会勒死 Scrum 团队的治理
人们常把治理与敏捷视为对立：一个要控制与可预测，另一个要速度与适应。可在实践中，二者彼此需要。2022 年开年伴随通货膨胀、材料与劳动力短缺以及磕磕绊绊的重返办公室，管理者希望有所监督是对的——但若把监督做成一道接一道的审批关卡，那恰恰会让 Scrum 团队变得迟缓、戒备，并对进展状况遮遮掩掩。诀窍在于治理结果与节奏，而非团队的每一个动作。
用好 Scrum 已经给你的东西
正如《Scrum 指南》所述，Scrum 框架建立在经验主义之上：透明、检视与适应。这本身就是治理——只不过不是开会加签字那一种。Sprint、Sprint 评审和产品待办列表，已经造就了定期且基于证据的检查点。在叠加新的控制之前，先问问：如果把 Scrum 事件做到位，它们能否承载你所需的监督？多数情况下，大部分都能。
Sprint 评审是你由需求驱动的状态会议——检视真实的增量，而不是一张百分比幻灯片。
由产品负责人排序的产品待办列表，是你关于优先级与取舍的鲜活记录。
完成的定义是你的质量关口，一次约定、每个 Sprint 都适用，而非反复争论。
Sprint 本身是一个固定长度的容器，把风险框住：你最多只会损失一个 Sprint。
治理边界，别去插手内部
健康的敏捷治理设好护栏，然后信任团队在其中行驶。管理者决定方向、预算和人人必须遵守的规则；Scrum 团队决定在这些之内如何交付。当压力上升——预算收紧、供应商交付不出、截止日期挪动——诱惑就是要求更多报告、更多审批。这通常买来的是控制的错觉，却拖慢了你正需要其迅捷的那支团队。
明确划定决策权。 写清楚哪些由 Scrum 团队自行决定，哪些需要发起人，哪些要上报。此处的含糊不清，要么催生鲁莽行动，要么造成瘫痪。
维护产品负责人对待办列表的权威。 若治理纵容指导委员会悄悄重排待办列表，就会摧毁问责。可以影响目标，但别夺走排序权。
让透明成为交易，而非额外文书。 团队承诺通过真实增量和最新的待办列表，做到诚实、可见的进展；作为交换，管理者不再索要那些只是复述 Sprint 评审已展示内容的平行状态汇报。
把拨款与成果挂钩，而非阶段关卡。 为一个目标拨款数个 Sprint，检视结果，再决定继续、转向还是停止。这比一次性的商业论证更严格的财务控制，也契合经验主义。
让合规适度。 在审计、安全或监管规则确实适用之处，把所需检查纳入完成的定义，使之在每个 Sprint 都发生，而不是拖到最后才手忙脚乱地集中处理。
如此治理，实际上提升了真正的控制力。由于团队每个 Sprint 都展示可用的增量，陷入麻烦的项目能被尽早看见，而此时改变方向的代价仍是一个 Sprint，而非一年。治理的意义不是为了让管理者安心而拖慢团队；而是确保所建之物正确、汇报诚实，并在不对劲时迅速叫停。
如果你想在不闷死敏捷团队的前提下保持强有力的监督，XNM 的项目与项目群交付咨询 可以帮你设计一套契合实际工作方式的治理。