Scrum@Scale®指南
Scrum@Scale权威指南：有效的规模化
版本1.0 – 2018年2月10日
©1993-2018 Jeff Sutherland和Scrum Inc.版权所有
Scrum@Scale是Scrum Inc.的注册商标
依据Creative Commons 4.0 Attribution-Sharealike License公共版权许可协议发布
Scrum@Scale指南的目的
Scrum，根据Scrum指南中的定义，是一个供单个团队开发、交付和维护复杂产品的框架。然而从开始构想Scrum框架的那一刻起，其使用就已经扩展到需要多个团队进行协作才能完成的产品、流程、服务和系统的创造过程中去。Scrum@Scale的创建是为了有效协调这个新的多团队生态系统，从而优化组织的总体战略。它通过一个可以不限规模增长的“最小可行的行政架构”来实现这一目标。它可以自然地将单个Scrum团队在工作方式扩展到了整个组织中去。
本指南定义了构成Scrum@Scale框架的组件，包括将单团队Scrum扩展到多团队所需要的扩展的角色、扩展的事件和企业级的组件，以及将这些组件连接在一起的规则。
Jeff Sutherland博士基于Scrum背后的基本原理、复杂适应性系统理论、博弈论和面向对象技术开发了Scrum@Scale。本指南是在许多经验丰富的Scrum践行者在他们一线工作成果的基础上编写的。本指南的目的是希望读者们能在读完本文之后可以自助实施Scrum@Scale。
为什么需要Scrum@Scale？
Scrum旨在让单个团队在能够保持可持续发展的同时以最优的效能工作。在实际工作中我们发现：随着组织中Scrum团队数量的增加，这些团队的产量和质量开始下降（常见的原因例如跨团队依赖、重复工作）。很显然，我们需要一个协作框架来有效协调多团队间的工作，使我们能够实现团队规模和产品规模的增长。Scrum@Scale旨在通过一个不限制增长规模的架构来实现这一目的。
通过利用不限制增长规模的架构，组织可以不受特定规则的约束而是基于其独特的需求来自然发展。这个自然发展的速度是可以被组织中的各团体所接受的、健康的、可持续发展的速度。
Scrum @Scale适用于整个组织：它可以横跨一个组织中的所有部门、产品和服务。它还可以被应用于不同行业、政府或学术机构及其他多个领域。
Scrum@Scale定义
Scrum（名词）: Scrum是一个框架，在这个框架内，人们可以解决复杂的适应问题，同时高效和创造性地交付尽可能最高价值的产品。
Scrum指南是一个最小可行的功能集，它通过彻底的信息透明来允许检视和适应以驱动创新、提升客户满意度并提高团队表现和幸福感。
Scrum@Scale（名词）：在此框架内，许多个相互关联的Scrum团队的运行与Scrum指南保持一致，这些团队可以协作解决复杂的适应问题，同时创造性地交付尽可能最高价值的产品。
注：这些“产品”可能是硬件、软件、复杂的集成系统、流程、服务等，。Scrum团队所在的领域决定其产品的形式。
Scrum@Scale是：
· 轻量级 – 最小可行的自组织决策机构
· 易于理解的 – 仅包含多个Scrum团队
· 难以精通的 – 需要实施新的运营模式
Scrum@Scale可以不限规模地扩大Scrum在一个组织里的应用。通过这个极其简单却十分有效的框架，组织可以通过使用Scrum来不断扩展其Scrum的应用。Scrum@Scale通过Scrum of Scrums和MetaScrums来协调众多Scrum团队之间的合作。
Scrum@Scale是一个组件化的框架。它允许各个组织自定义其转型策略和实施方案。它使得组织可以选择先聚焦在他们认为最有价值或最需要改变的领域进行转型工作，然后再发展到其他领域。
Scrum强调将“做什么”和“怎么做”的责任人区分开来。Scrum@Scale也采取同样的机制明确这两个问题的管辖权以避免不必要的组织冲突，从而提高团队的生产力。
为了分离这两个管辖区，Scurm@Scale包含了两个职能圈：Scrum Master职能圈（负责解决“怎么做”的问题）和产品负责人职能圈（负责回答“做什么”的问题）。这两个环有两个焦点两个职能圈相交，共同为协调多个团队的朝着一个方向努力提供了简单有效的合作框架。
Scrum@Scale®框架的组件
价值观驱动的文化
除了将“做什么”和“怎么做”的责任区分开，Scrum@Scale还旨在通过创造价值观驱动的文化来建立健康的组织。Scrum的价值观是：开放、勇气、专注、尊重和承诺。这些价值观依赖于透明、检视和适应这三大经验主义的支柱来驱动决策。
开放使所有工作的和流程得以透明。如果没有这种透明性，Scrum的践行者们就不能诚实地检视他们的工作和流程，也不可能进行适应和改进。勇气是指为了以创新的方式更快地交付价值愿意放手一搏。
专注和承诺是指我们处理工作职责的方式：将交付客户价值作为最高优先级。最后，所有这些都必须发生在一个每个个体都能被充分尊重的工作环境中。因为如果没有这些个体，我们便无法创造任何价值。
Scrum@Scale通过支持服务型领导力和以意向为基础的领导力模式1帮助组织发展。它为组织的可持续发展培育了一个积极的环境。同时，还帮助组织将其精力集中到交付客户价值的活动上去。
Scrum@Scale入门
在实现大规模的多团队协作之前，在小范围的团队中开发出一个可以复制推广的参考模型至关重要。值得注意的是，Scrum实施中的任何缺陷或不足都会随着实施团队的增加而被放大。
因此，我们遇到的第一个挑战就是要先建立一小批能很好实施Scrum的团队。这些团队在工作中会逐渐解决发现并解决一系列妨碍组织敏捷转型的问题。最终，这一小批团队对Scrum的应用会被认可为是在该组织中行之有效的实施Scrum的参考模型。通过这个模型我们可以将Scrum推向整个组织。
随着这一小批参考模型团队的不断成长，延迟交付、产生浪费以及影响业务敏捷性的障碍和瓶颈会变得越来越明显。消除这些障碍和瓶颈最有效的方法就是将Scrum推广到整个组织中去。只有这样，才能从整体上优化价值流。
Scrum@Scale通过在组织中充分渗透Scrum，以符合组织具体战略、产品和服务特性的方式自然地分配速度和质量来实现生产率的线性增长。
Scrum Master职能圈
团队层级的流程
团队层级的流程是Scrum Master职能圈和产品负责人职能圈之间的第一个交点。Scrum指南中对这个流程有明确的规定。它由三个工件，五个事件和三个角色组成。该流程的目标是：
· 最大化地让已完成的并通过质检的产品快速通过生产线
· 每个Sprint提高一点效率
· 团队以一种充实且可持续发展的方式运作
协调“怎么做” – Scrum of Scrums
几个有协作需要的团队组成一个“Scrum of Scrums”（SoS）。 SoS是一个“团队的团队”2，每个团队派代表参加Scaled Daily Scrum（SDS，即扩展的每日Scrum站会）。虽然代表通常会是团队的Scrum Master，但是每个团队可以根据需要派任意数量的最合适代表他们的人来参加SDS。SDS的存在是为了协调并且消除各团队间的合作阻碍从而交付价值。
SDS和每日Scrum站会大同小异。它优化了多个团队之间的协作和表现。此外，SDS还具有以下的特征：
· 时限为15分钟或更短。
· 每个团队必须有一名代表出席。
· 团队代表们在这个会议上讨论三个简单的问题：
· 我的团队遇到了什么障碍在阻止我们完成Sprint目标（或影响即将发布的版本）？
· 我的团队是否做了什么可能会阻碍其他团队完成其Sprint目标（或影响其即将发布的版本）的事情？
· 我们是否发现了任何团队之间的新的依赖关系？或者我们是否发现了任何可以解决现有依赖关系的方法？
2. 斯坦利·麦克里斯特尔 著，林爽喆 译，赋能：打造应对不确定性的敏捷团队 [Team of Teams]，中信出版社，2017
这个（主要）由Scrum Master们组成的团队本身就是一个Scrum团队– 他们负责各自所代表的团队在每个Sprint结束时有一组通过集成的潜在可交付产品增量。因此，SoS需要实时响应其参与团队所发现的障碍。
SoS作为一个发布团队必须能够直接为客户提供价值。为了有效地做到这一点，它需要与Scrum指南保持一致——也就是说，SoS要有自己的角色、工件和事件。此外，它还需要包括一个完善待办列表的事件。在这个事件中，SoS判断哪些障碍移除工作已经“准备就绪”、如何最好地移除这些障碍以及团队如何知道自己已经“完成了”障碍移除工作。另外，还应特别注意SoS的回顾会议。在回顾会议期间，各团队的代表们分享他们各自团队的经验或者是他们认为行之有效的流程改进方案，以便在SoS内的各团队中推广和规范这些实践。
SoS团队里需要具备各种技能以确保他们可以在每个Sprint结束时交付一个经过集成的潜在可交付产品。它有产品负责人代表来解决优先级问题。它可能需要经验丰富的架构师、QA负责人和具有其他业务能力的人。刚启动Scrum@Scale时，团队可能没有可以支持持续部署的架构。这可能使得SoS要去建立一个“集成团队”或“发布团队”来承担由现有技术缺陷所产生的额外工作。我们鼓励SoS去解决集成和部署的障碍因为它为超级生产力创造了一个环境。例如，亚马逊有3300个Scrum团队平均每秒钟部署一次以上3。
3. Monica, R. (2018). Personal Communication: Amazon Scrum Implementation. J Sutherland. Seattle, Amazon
SoS Master（SoSM）
SoS Master （SoS中的SoS Master类似于单个Scrum团队里的Scrum Master）对SoS里所有团队的共同发布成果负责并且必须：
· 让待消除障碍列表对整个组织透明可见。
· 移除团队无法自行解决的障碍。
· 对待消除的障碍进行排序，特别要关注团队间的依赖性和障碍在团队间的分布。
· 提高Scrumof Scrum的功效。
· 与产品负责人们密切合作，至少在每个Sprint里部署一个潜在可发布的产品增量。
· 根据产品负责人提供的发布计划协调各团队的部署。
扩大SoS
根据组织的规模和Scrum实施情况，有时可能需要多个SoS来交付一个非常复杂的产品。在这些情况下，多个SoS可以使用Scrum组成一个Scrumof Scrum of Scrums（SoSoS）。 SoSoS是Scrum团队的一种有机生长模式，它可以不限规模的增长。每个SoSoS都应该有SoSoS Master以及这个级别的Scrum所对应的工件和事件。
通过SoS来扩大Scrum的实施规模减少了组织内部的沟通路径、降低了复杂性。SoSoS与SoS接口的方式和SoS与单个Scrum团队接口的方式完全相同。这使得SoS可以线性增长 。
示例图：
注释：虽然Scrum指南将最佳团队规模定义为3到9人，但哈佛大学的研究表示最佳团队规模为4.6人4。对高效Scrum团队的研究也一再表明，4或5人是最佳的团队规模。这个数据对SoS中的团队数量也同样适用。这对于SoS的线性增长至关重要。也正因如此，上图和下文中的图片都选择五边形代表5人团队。这些图只是为了举例，你所在组织的示意图可能会有所不同。
4. Hackman, J Richard, Leading teams: Setting the stage for great performance, Harvard Business Press, 2002
主管行动团队（Executive Action Team）
整个组织里最高层的SoS被称为主管行动团队（EAT）。当障碍物无法由产生它的SoS消除时，EAT是它们的最后一站。因此，为了能有效消除障碍，EAT必须由在政策和财务上得到授权的个人组成。EAT的功能是协调多个SoS（或SoSoS）。与任何Scrum团队一样，它需要一个产品负责人（PO）和一个Scrum Master（SM）。理想的情况下，EAT和其他Scrum团队一样每天碰面。如果做不到，他们也至少要在每个Sprint里碰一次面并且要有一个透明的待办列表。
力 示例图显示了EAT协调5*25个团队
ETA的待办列表和职责
与传统项目不同管理，Scrum是一个敏捷的操作系统。EAT负责这套敏捷操作系统的安装和运行。整个Scrum Master组织向EAT汇报。EAT负责建立、维护和增强这套系操作系统在组织里的实施。。 EAT的职能是创建一个组织转型待办列表（一个按优先级排序的敏捷落地行动计划列表）并确保它被执行。例如，如果原来组织中使用传统的产品开发生命周期，EAT则需要创建、实施和支持新的敏捷产品开发生命周期。新的方法通常可以比旧的方法更好地支持质量和行业规定，但是需要以不同的方式和规则来实现。总之，组织发展和管理的很多方面可能都需要重新优化。
EAT对组织内部的Scrum质量负责。其职责包括但不限于：
· 为Scrum参考模型在组织里的推广创建一个敏捷的操作系统，包括企业运营规则、流程和指导方针。
· 测量和提高组织中Scrum的质量。
· 在组织内部建立业务敏捷性的能力。
· 为Scrum专业人员创建一个持续学习的中心。
· 支持探索新的工作方式。
最后，EAT必须建立并支持相应的产品负责人（PO）组织。PO组织效仿SoS的方式进行扩大。这些PO和关键干系人的团队被称为MetaScrums。
Scrum Master组织的产出/成果
Scrum Master组织（SoS，SoSoS和EAT）作为一个整体负责Scrum Master职能圈的其他组成部分：持续改进和障碍消除、跨团队协调以及部署。
持续改进和障碍消除的目标是：
· 识别障碍并将它们重塑为机遇。
· 维护一个安全且有规可循的环境对障碍进行排序和移除，然后对改进结果进行验证。
· 确保组织的信息透明以促进改变
跨团队协调的目标是：
· 协调多个相关团队使用相似的流程。
· 管理跨团队依赖关系，以确保它们不会阻碍团队的进度。
· 保持团队规范和产品质量具有一致性。
由于SoS的目标是起到一支发布团队的作用，因此他们对产品的版本发布负责。产品负责人则对发布版本的内容负责。产品部署的目标包括：
· 持续向客户交付有价值的产品。
· 将不同团队的工作成果无缝地整合成一个产品。
· 确保高质量的客户体验。
产品负责人职能圈
协调“做什么”– MetaScrum
一群需要相互协调并向某个Scrumof Scrum （SoS）提供待办列表的产品负责人们就是一个MetaScrum团队。每个SoS都有一个对应的MetaScrum。 MetaScrum协调多个团队，确保他们的优先级保持对齐并获得相关干系人的支持。MetaScrums负责多团队协作级别的待办列表梳理活动。
· 每个团队PO（或代理人）必须参加MetaScrum
· MetaScrum是管理层、干系人和其他客户表达他们意见的平台
·
待办列表梳理活动根据团队的具体需要发生，但至少每个Sprint要有一次，以确保待办列表准备就绪。MetaScrum的主要功能是：
· 为产品创建一个总体的愿景并使其对组织可见。
· 与关键干系人保持目标对其以确保他们支持功能的实现。
· 向团队提供一个唯一的、按优先级排序的待办列表避免重复工作。
· 创建统一的、适用于SoS中所有团队的“完成的定义”。
· 消除SoS发现的的依赖关系。
· 公布经过协调的发布计划。
· 监控产品的指标并根据其数据做决策。
MetaScrum，和SoS一样，作为一个独立的Scrum团队运行。因此，他们中需要有一个人充当SM（Scrum Master）的角色，确保团队在讨论中不离题。此外，他们还需要一个人负责协调MetaScrum成一个唯一的产品待办列表供MetaScrum里的所有团队使用。这个人被称为首席产品负责人（Chief Product Owner）。
首席产品负责人（CPO）
通过MetaScrum，首席产品负责人协调各团队产品负责人之间的优先级。CPO确保待办事项的优先级与干系人和客户的需求保持对齐。就像SoS Master一样，CPO可以是MetaScrum中某个团队的PO，他或她选择承担起CPO这个角色；CPO也可以是专职担任这个角色的人。
CPO的主要职责与PO相同，但是扩大到多个团队的层面：
· 为整个产品设定战略愿景。
· 创建一个唯一的、按优先级排序的待办列表由所有团队协作交付。- 这些待办事项通常比单个Scrum团队的PO所管理的用户故事要更大。
· 与他们相关的SoSM密切合作，以便MetaScrum团队生成的发布计划能够得到有效部署。
· 监控客户对产品的反馈并相应调整待办列表。
扩大MetaScrum
就像SoS可以发展为SoSoS一样，MetaScrum也可以通过相同的机制进行扩大。Scrum@Scale没有规定扩大之后的MetaScrum的命名术语，也没有规定它们对应的CPO的头衔。我们鼓励每个组织自行选择他们觉得合适的称呼和头衔。在下面的图表中，我们选择在这些PO的头衔放大时添加一个额外的“C”（Chief*表示首席的意思）。
一些示例图：
注意：如上所述，这些五边形代表理想大小的Scrum团队和理想大小的MetaScrum。这些图只是为了举例，你的组织图可能会有所不同。
主管MetaScrum（Executive MetaScrum或EMS）
MetaScrum是让产品负责人（PO）组织能与与其对应的SoS一起无限扩大的设计。整个敏捷组织的最高层级的MetaScrum被称作主管MetaScrum（EMS）。EMS拥有组织愿景、为整个公司设定战略重点、使所有团队向着组织的共同目标对齐。
示例图显示协调5组25个团队的EMS：
产品负责人组织的输出/成果
PO组织（MetaScrums，CPO和EMS）作为一个整体对产品负责人职能圈的其他各个组成部分负责。这些包括：战略愿景、待办列表优先级、待办列表的分解和精炼以及发布计划。
制定战略愿景的目标是：
· 保持组织向共同的目标对齐并朝着目标前进
· 令人信服地阐述组织存在的原因。
· 描述该组织将如何利用关键资源来支持其使命。
· 适应快速变化的市场。
对待办列表的优先级进行排序的目标是：
· 确定要交付的产品、功能和服务，明确待办列表的优先级。
· 在对待办事项进行排序的时候体现出对创造价值大小、是否能降低风险以及对内部依赖的考虑。
· 在待办列表分解和细化之前，对整个组织层面的项目进行排序
分解细化待办列表的目标是：
· 将复杂的项目和产品分解成多个独立的功能项，每一项可以由一个Scrum团队在一个Sprint中完成。
· 捕获和提炼新的需求和客户反馈。
· 确保所有待办事项都是真正“准备就绪”，以便各团队在他们觉得合适的时候可以顺利展开工作。
管理发布计划的目标是：
· 预测关键功能和能力的交付。
· 将交付期望传达给干系人。
· 根据需要修改优先级。
连接PO职能圈和SM职能圈
理解反馈
反馈组件是PO和SM职能圈的第二个交点。产品反馈通过调整产品待办列表来推动持续改进；同时，发布的反馈通过调整部署机制来推动持续改进。获取和分析反馈的目标是：
· 验证我们的假设。
· 了解客户如何使用产品并与之交互。
· 获取对特性和功能的新想法。
· 明确对现有功能的改进。
· 更新产品/项目完成进度，以确保发布计划和干系人的目标对齐。
· 确定部署方法和机制的改进。
度量指标和信息透明
彻底的信息透明对于Scrum的高效运作至关重要，但只有在接受Scrum价值的组织中才可能实现。这样的透明使组织有能力诚实地评估自己的发展并检视和适应其产品和过程。正如Scrum指南中所说，透明是Scrum基于经验性主义的基础。
SM和PO职能圈都需要由各自的SM和PO组织决定其各自的度量指标。不同组织或组织内的某些特定职能部门可能会具有自己独特的度量标准。Scale@Scrum不统一规定任何特定的度量集，但它确实建议组织至少应该测量：
· 生产力 – 例如每次Sprint交付的可工作的产品的量的变化
· 价值交付 – 例如平均每单位的团队工作可以创造多少商业价值
· 质量 – 例如缺陷率或服务停机时间
· 可持续性 – 例如团队幸福指数
使用度量和具备信息透明的目标是：
· 为所有决策者，包括团队成员，提供适当的信息以便他们做出正确的决定
· 尽可能缩短反馈周期以避免矫枉过正。
· 减少团队、干系人和管理层的额外工作。
关于组织设计的一些注意事项
Scrum@Scale的不限规模增长的特性允许组织采用基于组件化的设计。这使得组织可以为了响应市场需求而调整或重构团队。随着组织的发展，充分利用分布式团队带来的好处可能很重要。一些组织通过分布式团队获得了用其它方式无法获得的人才，并能够根据需要通过外包的方式扩展组织能力。Scrum@Scale展示了组织如何在自由扩张的同时避免长时间滞后、沟通不畅和质量下降的问题。，从而实现了规模化和全球分布化的线性可扩张5。
5Sutherland, 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
在这个组织图中，空心五边形代表了知识和基础设施两个虚拟团队。，由于具有这些特殊技能的员工很少，无法给组织里的每个团队都配置一个全职的成员。因此，他们通过服务级别协议与其他Scrum团队进行协作。其他团队将需求发送给虚拟团队的PO，PO将所有的需求列入一个透明的、按优先级排序的待办列表。值得注意的是，这些虚拟团队不是孤立的职能团队（这就是为什么用空心五边形来代表他们的原因）。事实上，他们的团队成员平时是和其他Scrum团队成员坐在一起办公的。，他们组成了虚拟的Scrum团队，是为了更好地实现对待办列表的沟通和对工作流程的改进。
客户关系、法律和人员运营也包含在这个组织图中。它们是组织的必要组成部分并且作为独立的Scrum团队存在。组织中其他团队的日常运转可能会依赖于这几个团队。
关于EAT＆EMS的说明：在该图中EAT和EMS是重叠的，因为有一部分成员同时参加了这两个团队。在小型的组织或小规模的实践中，EAT和EMS可能完全由相同的团队成员组成。
结束注释
Scrum@Scale旨在扩大生产力。它希望使整个组织以一半的时间完成两倍的工作同时具有更高的产品质量和经过显著改善的工作环境。正确实施Scrum@Scale的大型组织可以降低其产品和服务的成本，同时改善质量和创新。
Scrum@Scale旨在让Scrum遍及整个组织。让包括管理层、人力资源、法律、咨询培训以及产品和服务团队在内的所有团队实施相同风格的Scrum，并在实施的同时精简和提高组织。
实施良好的Scrum可以经营整个组织。
致谢
感谢IDX创造了Scrum of Scrum，第一次允许Scrum扩展到数百个团队。感谢PatientKeeper发明了MetaScrum用于快速部署创新产品。感谢OpenView Venture Partners将Scrum的应用扩大到他们的整个组织。我们感谢英特尔的经验 —— 在一个超过25,000人使用Scrum的组织里只有可以线性增长的架构才能满足他们的扩张需求。另外，还要感谢最大的Scrum组织- SAP。他们教会我们：管理层参与MetaScrum对2,000个Scrum团队一起工作起到的必要性。
感谢在亚马逊，通用电气，3M，丰田，Spotify以及其他许多与Jeff Sutherland合作的公司里实的敏捷教练和培训师。感谢他们在不同的公司和领域实施和测试这些概念。
最后，感谢Avi Schneier和Alex Sutherland在制定和编辑这份文档时提供的帮助。
翻译
这份Scrum@Scale中文版指南是由David Han翻译，Ma Kai、Zhang Xiao、Jim Wang审校。
欢迎转载且备注文章出处和作者，您在转载时请发送信息至info@shinescrum.com邮箱或小窗联系我们，请勿私自转载。感谢配合！
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/295329.html