SCRUM@SCALE指南

本指南发布于知识共享署名-相同方式共享 4.0 国际许可协议之下。

英文版原文链接：https://www.scrumatscale.com/scrum-at-scale-guide-read-online/

中文版由Jerry Li（李洁）翻译，Eric Liao（廖靖斌）审校。

SCRUM@SCALE指南的目的

Scrum，最初概述于《Scrum指南》，是一个单团队开发、交付和维护复杂产品的框架。自从问世以来，其应用已经拓展到需要多个团队协作才能完成的产品、事务过程、服务和系统。Scrum@Scale的创建，是为了通过优化组织整体战略，以高效协调多团队的新生态系统。它通过采用一个“可自由扩展的架构（Scale-Free）”，建立起一个“最小可行的管理机构”，将单个Scrum团队的功能自然地扩展到整个组织，以达成此目标。

本指南包含构成Scrum @ Scale框架的组件定义，包括扩展角色、扩展事件和组织工件，以及把它们组织在一起的规则。

Jeff Sutherland博士基于Scrum背后的基本原则、复杂适应系统理论、博弈论和面向对象技术开发了Scrum@Scale。许多富有经验的Scrum从业者基于他们的实战成果为本指南提供了素材。本指南的目标是使读者能够独立实施Scrum@Scale。

为什么需要SCRUM@SCALE

Scrum是为使单个团队而设计，使其能以维持可持续节奏工作于最佳产能。在实战中，人们发现，随着组织的扩张以及Scrum团队数量的增长，团队们的最佳产出（可工作的产品）以及团队速率在开始下降（由于诸如跨团队依赖和重复劳动之类的问题）。显然，为了实现组织的线性可扩展性，需要一个能有效协调多团队的框架。Scrum@Scale通过它的“可自由扩展的架构（Scale-Free）”的设计方式，来达成这个目标。

通过采用可自由扩展的架构，组织的扩张不再局限于特定规则下的特定方式；取而代之的是，它可以基于其独特的需求，以及被组织成员群体接受的可持续变化节奏，有机地扩展。

Scrum@Scale被设计为在组织整体层面进行扩展，覆盖了所有的部门、产品和服务。它可以应用于行业、政府或学术的各类组织机构的多个领域。

SCRUM@SCALE的定义

Scrum(名词)： 是一个框架，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付最高可能价值的产品。

《Scrum指南》是一套最小特征集，通过彻底的透明来促使检视和适应，以促进创新，提升绩效和团队的幸福感。

Scrum@Scale(名词)：是一个框架，遵从《Scrum指南》运作的多个Scrum团队组成的网络组织能够使用此框架来解决复杂的自适应难题，同时也能创造性地交付最高可能价值的产品。

说明：这里的“产品”，可以是硬件、软件、复杂集成系统、事务过程、服务等等，这取决于Scrum团队们所处的领域。

Scrum@Scale 是:

• 轻量的 – 最小可行的管理机构
• 易于理解的 – 由且仅由单个或多个Scrum团队组成
• 难以精通的 – 需要实施全新的运作模式

Scrum@Scale是一个用于扩展Scrum的框架。它通过使用Scrum来扩展Scrum，彻底简化了扩展方式。它由且仅有通过SoS（Scrum of Scrums）及MetaScrum来协调的Scrum团队们组成。

Scrum@Scale具有基于组件的天性，这就允许组织自行定制其转型策略和实施方式。它赋予转型组织能力，使他们能先把转型工作聚焦于其认为最有价值或者最需要变革的区域，然后再向其他区域推进。

在Scrum中，关注从职责上分离“做什么”和“怎么做”。在Scrum@Scale中，也同样关注这一点，以期明确权力和责任，消除会妨碍团队们实现最佳生产率的浪费性组织冲突。

在分离这两种权力时，Scrum@Scale包含了两个循环：Scrum Master循环（负责“怎么多”）和产品负责人循环（负责“做什么”），彼此相交于两个点。总体来说，这两个循环产生了一个能协调多个团队往一处使劲的强有力框架。

SCRUM@SCALE框架的组件

价值观驱动的文化

除了分离“做什么”和“怎么做”的职责外，Scrum@Scale进一步旨在建立健康的组织，这是通过在经验主义环境中打造价值观驱动的文化来实现的。Scrum的价值观为：开放、勇气、专注、尊重和承诺。这些价值观驱动着经验决策，后者依赖于透明、检视和适应这三大支柱。

开放，才能保证透明深入到所有的工作和过程；缺乏这种价值观，就无法做到对工作和过程进行真诚地检视和改进。勇气，指的是采取必要而大胆的变革，以创新的方式更快地交付价值。

专注和承诺，指的是我们对待自己工作义务的方式，要把客户价值交付置于最高优先级。最后，所有这些都只会发生于以尊重工作人员为本的环境中，失去了人也就无法产出物。

Scrum@Scale通过支持服务型领导风格和基于意图的领导模式【1】，来帮助组织茁壮成长；这就营造了一个积极的环境，以期用可持续的节奏工作，承诺把客户价值交付作为首要事务。

启动SCRUM@SCALE

在实现大型Scrum团队网络时，关键是要先针对一个小规模团队集开发出一个可扩展的参考模型。任何Scrum实施上的短板在部署到多个团队时都将被放大。

因此，面临的第一个挑战是，要先建立起一个能够良好实施Scrum的小规模团队集。这个团队集要解决那些阻碍敏捷的组织问题，并为实施Scrum建立一个参考模型；这个参考模型将会被引入到组织中，作为在整个组织范围内扩展Scrum的模式。

随着这个参考模型的加速，延迟交付、制造浪费或妨碍业务敏捷性的障碍及瓶颈将会一一显现出来。而最有效的问题解决手段就是将Scrum扩展到整个组织，在整个价值链条上做优化。

Scrum@Scale通过在组织中贯彻落实Scrum，以及有机地分配速度和质量，来实现生产率与组织具体战略、产品和服务的同步线性增长。

SCRUM MASTER循环

团队级过程

在《Scrum指南》中明确阐述了团队级过程。它由三个工件、五个事件和三个角色组成。团队级过程的目标是：

• 使已完成且通过品质测试的工作最大程度地流动起来。
• 每个冲刺都能在团队速率上得到少许提升。
• 以一种对团队来说既可持续又极为充实的方式来运作。

协调“怎么做”-SCRUM OF SCRUMS，缩写为SOS

需要彼此协作的团队可以组建一个“Scrum of Scrums（SoS）”。 SoS是一个跨团队协作的Scrum团队，它有一个跨团队的Scrum每日例会（Sacled Daily Scrum），简称：SDS。 每个团队都会派代表参加SDS,尽管团队中的任何人或者任意数量的人都有可能参加SDS，但通常是Scrum Master参加。SDS的存在是为了协调团队，以及消除团队交付价值的障碍。

SDS事件类似于每日Scrum站会，在会上优化团队网络的协作和效能。此外，SDS：

• 时间被限制在15分钟以内。
• 每个团队必须派代表参加会议。
• 是一个团队代表们解决三个简单问题的讨论会：
• 本团队有什么障碍会妨碍其他团队完成其冲刺目标（或者影响即将到来的发布版本）？
• 本团队是否正在做任何会妨碍其他团队完成其冲刺目标（或者影响即将到来的发布版本）的事情？
• 我们是否发现了任何新的跨团队依赖，或者发现了现存依赖的解决方法？

这个由Scrum Master们组成的团队本身就是一个Scrum团队，负责在每个冲刺结束时从所有参与的Scrum团队中集成得到完整的潜在可交付产品增量。这个SoS需实时响应各参与团队提出的障碍。

SOS作为一个发布团队来运作，必须能够直接向客户交付价值。要做到这一点，它需要遵循《Scrum指南》，也就是说，要有自己的角色、工件和事件。这包括待办列表精化事件，在其中他们决定哪些障碍已经“准备好”被消除、最好该如何消除，以及团队如何知晓事情已经“完成”。还应该特别关注SoS回顾会议，团队代表们在会上分享各个团队学到的经验和成功实施的过程改进，以便在SoS内部标准化那些跨团队实践。

为了在冲刺结束时能交付一个完整集成的潜在可交付产品，SoS必须具备所有必需的技能。它包括产品负责人的代理人，负责解决优先级问题。它可能需要经验丰富的架构师、QA负责人，以及其他具有操作技能的人们。在刚开始启动Scrum@Scale时，团队可能还不具备支撑持续部署的基础设施。这会迫使SoS不得不建立一个“集成团队”或“发布团队”，这是为了克服工程技术缺陷而产生的额外工作。鼓励SoS去积极地解决集成和部署障碍，以打造实现超高生产率所需的环境，例如亚马逊有3300个Scrum团队，平均每秒部署一次以上【3】。

SOS MASTER（THE SCRUM OF SCRUMS MASTER，缩写为SOSM）

SoS Master（the Scrum of Scrums Master，缩写为SoSM）对团队们联合产出的发布版本负责，必须做到：

• 制定组织可见的障碍待办列表。
• 消除各个团队无法自行解决的障碍。
• 对障碍进行优先级排序，并特别关注跨团队依赖和待办列表的分布情况。
• 提升SoS的效能。
• 与产品负责人们密切协作，在每个冲刺中至少部署一个潜在可发布产品增量。
• 结合产品负责人的发布规划，协调各个团队的部署工作。

扩展SOS

基于组织和实施团队的规模，交付非常复杂的产品可能需要多个SoS协作。在这种情况下，在多个Scrum of Scrum之上，可以建立一个Scrum of Scrum of Scrums（SoSoS）。SoSoS是Scrum团队群的一个有机模式，可以无限扩展。每个SoSoS应该有自己的SoSoS Master（缩写：SoSoM），以及每个工件和事件的扩展版本。

通过扩展SoS，可以减少了组织内的沟通路径数，使复杂度得到封装。SoSoS与SoS的协作方式，同SoS与单个Scrum团队的协作方式完全相同，这就为组织提供了线性可扩展性。

示例图：

说明：尽管《Scrum指南》定义团队的最佳规模是3到9人，但哈佛大学研究确定的团队最佳规模是4.6人【4】。针对高效Scrum团队的实验也一再表明，4或5人是最佳的协作规模。在本模式中一个SoS包含的团队数量也采用了这个数值，这是线性可扩展性的关键之处。因此，在上面和接下来的图中，选择使用五边形来代表一个5人的团队。这些图仅仅是示例而已，您的组织图可能会有很大的差别。

决策层行动小组（EXECUTIVE ACTION TEAM，缩写为EAT）

针对整个敏捷组织的SoS，称为决策层行动小组（Executive Action Team ，缩写为EAT）。各个SoS不能消除的障碍，最终会反馈到EAT。因此，它必须由在行政上和财务上得到充分授权的个体组成，才能消除障碍。EAT的职能是协调多个SoS（或多个SoSoS）。同Scrum团队一样，它也需要一个PO和一个SM。EAT最好能像Scrum团队一样每天碰面。每个冲刺他们必须至少碰面一次，并有一个透明的待办列表。

展示1个EAT协调5组25个Scrum团队的示例图

EAT的待办列表和职责

Scrum是一个区别于传统项目管理的敏捷运作系统。整个SM组织向EAT汇报，EAT负责通过建立、维护和强化组织中的执行，来实施这个敏捷运作系统。EAT的角色职责是创建一个组织变革待办列表（经过优先级排序的待完成敏捷事项清单），并跟进执行落地情况。例如，如果原先组织中存在传统的产品开发生命周期，那么就必须创建、实施和支持一个全新的敏捷产品开发生命周期。它通常能比旧方法更好地支持质量和合规性问题，但是会以不同的方式和不同的规则及准则来实施。

EAT对组织内的Scrum质量负责。其职责包括但不限于：

• 在组织范围内为参考模型创建一个敏捷运作系统，包括企业运作的规则、规程和指南，以使敏捷能得以实施。
• 度量和改进组织中的Scrum质量。
• 在组织内打造业务敏捷性能力。
• 为Scrum专业人员创建一个持续学习中心。
• 支持探索新的工作方式。

最后，EAT必须以类似SoS的形式把PO们也组织起来，建立和支持一个相应的产品负责人组织，以扩展他们的PO功能。这些由PO和关键干系人们组成的团队称为“MetaScrum”。

SCRUM MASTER组织的产出/成果

SM组织（SoS、SoSoS和EAT）作为一个整体，协同完成Scrum Master循环中的其他组件：持续改进、消除障碍、跨团队协调和部署。

持续改进和消除障碍的目标是：

• 识别障碍并把它们转化为组织改进的机会。
• 维护一个安全和结构化的环境，以对障碍进行优先级排序，消除障碍并验证由此带来的改进。
• 确保组织中的可见性，以促进变革。

跨团队协调的目标是：

• 协调跨多个相关团队的类似过程。
• 管理跨团队依赖，确保它们不会转变为障碍。
• 维护团队规范和准则的一致性，以确保输出一致。

既然SoS的目标是作为发布团队来运作，产品的部署也在其职责范畴内，而在发布版本中发布什么内容则属于产品负责人们的职责范畴。因此，部署的目标是：

• 向客户持续地交付有价值的成品。
• 把来自不同团队的工作成果集成为一个无缝的产品。
• 确保客户体验的高质量。

产品负责人循环

协调“做什么”– MetaScrum

一个SoS需要一份唯一的产品待办列表作为输入，负责整合这份产品待办列表的这些产品负责人自身构成一个称为“MetaScrum”的团队。每个SoS都有一个相关的MetaScrum。MetaScrum将所有团队的优先级沿着一条路径进行排列，以便整合产品待办列表，并通过与干系人达成一致来获得他们对整合后产品待办列表的支持。各个MetaScrum会执行多团队的当前发布的产品待办列表精化。

• 每个团队的PO（或者PO代理人）都必须参加。
• 这个事件是一个供领导层、干系人或其他客户表达他们喜好的讨论会。

这个事件按需执行，每个冲刺至少会执行一次，以确保提供一个就绪的产品待办列表。MetaScrum的主要职能是：

• 为产品规划一个总体愿景并使其对组织可见。
• 与关键干系人达成一致，以确保其支持产品待办列表的实施。
• 生成一份唯一的、经过优先级排序的产品待办列表，确保避免重复劳动。
• 创建一个统一的“完成的定义”，应用于SoS中的所有团队。
• 消除SoS提出的依赖。
• 生成已整合的发布规划。
• 决定采用哪些度量指标来洞察产品，并执行监控。

类似于SoS，MetaScrum自身也像Scrum团队一样运作。因此，他们需要有人担任SM并确保团队在讨论时不偏离方向。他们还需要有一个人负责协调本MetaScrum的所有团队，整合出一份唯一的产品待办列表。这个人被称为首席产品负责人（Chief Product Owner，缩写为CPO）。

首席产品负责人（CHIEF PRODUCT OWNER ，缩写为CPO）

通过MetaScrum，CPO与各个团队的产品负责人协调优先级顺序。他们依据干系人和客户需要来对产品待办列表进行优先级排序。就像SoSM一样，CPO可以选择由某个团队PO担任，也可以由某个专职人员来担任。CPO的主要职责同普通PO是完全一样的，只不过是扩展层面的：

• 规划整个产品的战略愿景。
• 创建一份唯一的、经过优先级排序的产品待办列表，包括所有团队要交付的价值。
• 与单个团队PO的产品待办列表项相比，这些产品待办列表项可能是更大的故事。
• 与相关的SoSM密切协作，使MetaScrum团队生成的发布规划得到高效部署。
• 监控客户的产品反馈，并对产品待办列表进行相应的调整。

扩展METASCRUM

就像SoS能扩大为SoSoS一样，MetaScrum也能采用同样的机制进行扩展。这些扩展单位没有专门的术语，其CPO也没有专门的扩展头衔。我们鼓励每个组织自行定义这些术语和扩展头衔。在下图中，当PO团队扩大时，我们选择添加一个额外的“首席（Chief）”修饰词到其头衔中。

一些示例图：

说明：如上所述，这些五边形代表着理想规模的Scrum团队和理想规模的MetaScrum。这些图仅仅是示例而已，您的组织图可能会有很大的差别。

决策层METASCRUM（EXECUTIVE METASCRUM ，缩写为EMS）

MetaScrum使我们能够设计一个产品负责人网络，这个网络能与相关的SoS一起无限扩展。针对整个敏捷组织的MetaScrum，即为决策层MetaScrum（Executive MetaScrum ，缩写为EMS）。EMS拥有组织愿景并为整个集体设置战略优先级，使所有团队都围绕共同目标调整一致。

显示一个EMS协调5组25个团队的示例图：

产品负责人组织的产出/成果

PO组织（各个MetaScrum，CPO和EMS）作为一个整体，协同实现产品负责人循环的组件：战略愿景、待办列表优先级排序，待办列表分解&精化，和发布规划。

规划战略愿景的目标是：

• 使整个组织沿着一条共享的前进路径清晰地调整一致。
• 令人信服地表明组织存在的意义。
• 描述组织将如何撬动关键资产以支持其使命。
• 持续地更新，以应对快速变化的市场环境。

待办列表优先级排序的目标是：

• 将待交付的产品、特性和服务，确定一个清晰的优先级顺序。
• 在待办列表的排序中，要反映出价值创造、风险缓解和内部依赖。
• 在待办列表分解和精化前，先在整个敏捷组织层面进行高级事项的优先级排序。

待办列表分解&精化的目标是：

• 把复杂的项目和产品分解成独立的功能单元，这些单元应当能由单个团队在一个冲刺内完成。
• 捕获和提炼浮现出的需求和客户反馈。
• 确保所有的待办列表项都是真地“就绪”，以便能够被各个团队领取。

发布规划的目标是：

• 预报关键特性和能力的交付。
• 与干系人沟通交付预期。
• 必要时更新优先级。

理解反馈

反馈组件是PO与SM循环的第二个交点。产品反馈通过调整产品待办列表来驱动持续改进，而发布反馈则通过调整发布机制来驱动持续改进。获取和分析反馈的目标是：

• 验证我们的假设。
• 理解客户如何使用产品以及如何与产品交互。
• 捕获对新特性和新功能的创意。
• 定义现有功能的改进点。
• 更新产品/项目的进展，提炼发布规划并与干系人达成一致。
• 识别对部署方式和部署机制的改进点。

度量和透明

彻底的透明是Scrum能最佳运作的关键，但这只可能出现在拥抱Scrum价值观的组织中。它赋予组织真诚地评估其工作进展，以及检视和改变产品及过程使之更适应的能力。正如《Scrum指南》所阐述的那样，这是Scrum的经验主义本质的根基。

SM循环和PO循环都需要度量，具体的度量指标分别由SM组织和PO组织决定。对于这两个特定组织以及这两个组织中的特定职能来说，度量指标可能是唯一的。Scrum@Scale并不需要任何特定的度量指标集，但是它确实建议组织在最低程度上应当度量：

• 生产率 – 例如，每冲刺的交付可用产品量的变值
• 价值交付 – 例如，每单位团队工作量的商业价值
• 质量 – 例如，缺陷率或服务宕机时间
• 可持续性 – 例如，团队的幸福感

度量和透明的目标是：

• 向所有决策者（包括团队成员）提供适度的背景信息，以便做出正确的决策。
• 尽可能缩短反馈周期，以避免矫枉过正。
• 要尽可能地减少团队、干系人或领导的额外投入。

关于组织设计的一些说明

Scrum@Sacle的“可自由扩展（Sacle-Free）”的自然属性，使得我们可以基于组件的方式设计组织架构，就像这个框架自身一样。它让我们可以根据市场需要进行团队的重构和再平衡。随着组织的发展，获得分布式团队的好处可能是很重要的。通过开发外包，一些企业获得了其它方式无法获得的人才，并按需进行扩张和雇用。Scrum@Sacle展示了如何做到这一点，同时避免过长的滞后时间，妥协的沟通和低劣的质量，使其可以在组织规模和全球分布上都可以线性扩展。

在这张组织图中，知识团队和基础设施团队代表由专家组成的虚拟团队，由于专家人数太少而不可能为每个团队都配备。他们作为一个小组与Scrum团队们通过服务等级协议进行协作，小组中为每个专业都设置了一位PO，所有对某专业的服务请求都必须流经该专业的PO，并由PO负责把服务请求转化为透明的、经过优先级排序的待办列表。需要重点说明的是，这些团队并不是所有成员都坐在一起的集中封闭式团队（这就是他们被表示为空心五边形的原因）；他们的团队成员都坐在实际的Scrum团队中，但他们自身组成了这个虚拟Scrum团队，以实现在组织中散播待办列表和过程改进。

这里也包括客户关系、法律/合规，以及人力运营，因为他们也是组织不可或缺的部分，并且将会作为独立的Scrum团队而存在，其他所有团队可能都会依赖他们。

最后再说明一下对EAT和EMS的表示：在这张图中，他们显示为重叠的，因为有2位成员在两个团队中都存在。在非常小的组织或实施中，EAT和EMS可以由完全相同的一组成员组成。

结束语

Scrum@Scale是为提高生产率而设计的，旨在使整个组织在改善质量和显著改善工作环境的情况下实现事半功倍。在大型组织中恰当地实施本框架，可以降低产品和服务的成本，同时提高质量和促进创新。

Scrum@Scale是为了能让组织贯彻和执行Scrum而设计的。所有的团队，包括领导、人力资源、法律、咨询和培训，以及产品和服务团队，实施相同风格的Scrum，同时精简和强化组织。

良好实施的Scrum能够运作起整个组织。

致谢

我们感谢IDX创建了SoS，这使得Scrum可以扩展到几百个团队【6】；感谢PatientKeeper 创建了MetaScrum【7】，这使得创新产品得以快速部署；感谢OpenView Venture Partners把Scrum扩展到整个组织【8】。我们看重来自Intel的输入，超过25000人在执行Scrum，这教会我们——除了一个“可自由扩展的架构外（Sacle-Free）”“没有什么能扩展”；SAP拥有最大Scrum团队规模的产品组织，教会我们——管理层参与到MetaScrum中，是实现2000个Scrum团队协作的关键。

那些在亚马逊、GE、3M、丰田、Spotify和其他许多公司与Jeff Sutherland一起工作和实施这些概念的敏捷教练和培训师们，为在不同领域的众多公司中验证这些概念提供了帮助。

最后，Avi Schneier和Alex Sutherland对本文档的制作和编辑有着无法估量的价值。

参考资料：

1. Marquet, L David, Turn the Ship Around!: How to Create Leadership at Every Level, Greenleaf Book Group, 2012
2. McChrystal, General Stanley and Collins, Tantum and Silverman, David and Fussell, Chris, Team of teams: New rules of engagement for a complex world, Penguin, 2015
3. Monica, R. (2018). Personal Communication: Amazon Scrum Implementation. J. Sutherland. Seattle, Amazon.
4. Hackman, J Richard, Leading teams: Setting the stage for great performances, Harvard Business Press, 2002
5. Sutherland, Jeff and Schoonheim, Guido and Rustenburg, Eelco and Rijk, Maurits, “Fully distributed scrum: The secret sauce for hyperproductive offshored development teams”, AGILE’08. Conference, IEEE: 339-344, 2008
6. Sutherland, Jeff, “Inventing and Reinventing SCRUM in five Companies”, Sur le site officiel de l’alliance agile, 2001
7. Sutherland, Jeff, “Future of scrum: Parallel pipelining of sprints in complex projects”, Proceedings of the Agile Development Conference, IEEE Computer Society 90-102, 2005.
8. Sutherland, Jeff and Altman, Igor, “Take no prisoners: How a venture capital group does scrum”, Agile Conference, 2009. AGILE’09, IEEE 350-355. 2009