多年来，人们对 ScrumMaster 角色的定义一直过于狭窄。ScrumMaster 安排 Scrum 事件、更新看板、跟踪行动项、移除障碍，并帮助团队遵循敏捷实践。这些活动当然有价值，特别是对于刚开始实践 Scrum 的团队。但是，这些从来都不是 ScrumMaster 角色所能创造的最高价值。而在 AI 时代，如果 ScrumMaster 的主要工作仍然停留在这些事务上，那么就越来越难证明为什么这个角色需要成为一个全职的领导岗位。

目前有三股力量正在同时推动这一变化：

AI 自动化

越来越多的日常协调和行政性工作都可以被AI自动化，例如准备会议议程、会议总结、记录行动项、分析Product Backlog、识别回顾会议中的主题。

如果一个角色的主要价值集中在这些工作上，它必然会持续面临压力。

随着团队逐渐内化敏捷实践，他们需要的“框架管理”越来越少。过去可能需要专门的促进者才能完成的事情，会逐渐成为团队日常工作方式的一部分。

企业越来越需要能够超越单个团队、优化整体价值和流动的领导者。他们需要关注整个价值交付系统，包括：需求进入 → 优先级排序 → 容量 → 交付 → 发布 → 客户价值。

2023年，Capital One成为这一趋势中非常引人注目的案例。它取消了Agile专职岗位体系，并将敏捷交付能力整合到工程和产品管理岗位中。这里真正值得关注的信息不是“企业不再需要敏捷领导力。”而是“企业越来越不会支持一个仅仅负责管理敏捷框架的岗位。”

真正的问题不是企业是否仍然需要敏捷领导力？而是敏捷领导力未来应该演变成什么？

核心理念：从ScrumMaster到Delivery Lead

有五个关键转变正在重新定义什么叫做“高价值的 ScrumMaster”。每一个转变背后都反映了不同的变化：AI 能力的提升、组织成熟度的提高、对跨团队交付优化的需求，以及对价值和结果的关注。这些变化共同指向一个正在出现的新角色：Delivery Lead —— 交付负责人。

这个角色的价值不再通过“主持了多少 Scrum 事件”来衡量，而是通过判断力、流动、自适应规划、风险管理和价值交付来衡量。

1.流程促进者 → 交付领导者

2.团队障碍 → 端到端价值流

3.Sprint Planning → 自适应容量管理

4.行政支持 → AI 增强的判断力

5.团队教练 → 人机协作的变革领导者

旧模式主持 Scrum 事件，并保护流程

演进中的模式把团队的活动与可衡量的交付结果连接起来

为什么会发生这种转变？

Scrum Guide 从来没有把 ScrumMaster 定义成单纯的“会议主持人”。ScrumMaster 对Scrum Team的有效性负责，同时也是一个服务团队和组织的领导者。其重要职责包括：教练团队实现自管理，帮助团队专注于高价值 Increment，移除障碍，支持基于经验主义的产品规划，改善利益相关者协作。

但在实际工作中，很多组织把ScrumMaster简化成主持Daily Scrum、Sprint Planning、Sprint Review和Sprint Retrospective。而现在AI已经可以帮助准备议程、总结讨论、记录行动项、分析 Backlog 质量以及提议回顾会议主题。因此，如果ScrumMaster的主要工作集中在这些活动上，这个角色必然会受到越来越大的压力。

未来的 ScrumMaster 应该减少花在“管理 Scrum 事件”上的时间，而开始提出一个不同的问题。不再只是问：“我们是不是正确地在做 Scrum？”而是问：“我们是否能够有效地把优先事项转化为价值？”因此，ScrumMaster 会减少会议和流程管理、行政协调，并增加结果导向（Outcome Framing）、利益相关者对齐，以及找出真正拖慢交付速度的约束。

结果导向 ◆ 商业理解力 ◆ 利益相关者沟通 ◆ 数据驱动的引导 ◆ 自管理教练

1.当我描述自己一周的工作时，有多少时间是在主持会议，又有多少时间是在改善结果？

2.如果我不在场，团队是否仍然能够有效地运行 Scrum 事件？

3.利益相关者把我看成是一个“汇报交付情况的人”，还是“改善交付的人”？

旧模式解决团队边界以内的障碍

演进中的模式优化整个交付系统的流动

为什么会发生这种转变？

真正影响交付的最大约束，往往并不局限在一个团队内部。它们可能存在于：

● 分散的需求入口

● 相互竞争的优先级

● 跨团队依赖

● 架构审批队列

● 合规流程

● 缓慢的决策

● 不稳定的团队容量

● 以项目而非产品为中心的治理机制

针对29个团队、53名实践者的研究发现，ScrumMaster在早期往往承担多种领导职能。随着团队逐渐建立信任、心理安全、共同目标、透明度和自我效能感，ScrumMaster会逐渐把这些职责转移给团队。优秀ScrumMaste不应该让团队永久依赖ScrumMaster。当团队越来越能够自管理时，ScrumMaster的关注点应该向外扩展——转向整个价值交付系统。

实践中会发生什么变化？

ScrumMaster可能会解决一个被阻塞的User Story，或促进一次困难的团队讨论。而 Delivery Lead还需要看到工作如何流经整个系统：

需求 → 优先级 → 容量 → 交付 → 发布 → 客户反馈

Delivery Lead 需要让瓶颈可视化、减少 WIP（在制品）、升级系统性约束、改善跨团队协作，并帮助管理层改变真正拖慢交付的政策和组织结构。

需要培养的能力

◆ 流动指标

◆ 系统思维

◆ 依赖管理

◆ WIP 管理

◆ 跨团队协调

1.我能说出三个位于团队控制范围之外、却严重影响流动的最大约束吗？

2.我是否跟踪流动指标，还是只看 Sprint 完成情况？

3.当团队越来越能够自管理时，我接下来应该把注意力放在哪里？

原文：LitheSpeed, The Evolving ScrumMaster (2026)