SCRUM@SCALE指南- 20210903 思维导图模板_ProcessOn思维导图、流程图

价值观驱动的文化

建立健康的组织

在经验主义环境中打造价值观驱动的文化

Scrum的价值观
驱动经验决策

Scrum的价值观

开放

保证透明深入到所有的工作和过程

缺乏

无法做到对工作和过程进行真诚地检视和改进

勇气

采取必要而大胆的变革

以创新的方式更快地交付价值

专注

承诺

尊重

以尊重工作人员为本

三大支柱

透明

检视

适应

Scrum@Scale

支持服务型领导风格

基于意图的领导模式

帮助组织茁壮成长

营造积极环境

用可持续的节奏工作

承诺把客户价值交付作为首要事务

启动SCRUM@SCALE

实现大型Scrum团队网络时

先针对一个小规模团队集开发出一个可扩展的参考模型

任何Scrum实施上的短板在部署到多个团队时都将被放大

首先建立小规模scrum团队集

能够良好实施

解决那些阻碍敏捷的组织问题

一个参考模型

引入到组织

作为在整个组织范围内扩展Scrum的模式

参考模型的加速

延迟交付

制造浪费

妨碍业务敏捷性的障碍及瓶颈

解决手段

将Scrum扩展到整个组织

在整个价值链条上做优化

Scrum@Scale

在组织中贯彻落实Scrum

有机地分配速度和质量

实现同步线性增长

生产率

组织

具体战略

产品

服务

SCRUM MASTER循环

团队级过程

组成

三个工件

五个事件

三个角色

目标

使已完成且通过品质测试的工作最大程度地流动起来

每个冲刺都能在团队速率上得到少许提升

以一种对团队来说既可持续又极为充实的方式来运作

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

Scrum of Scrums（SoS）

彼此协作的团队可以组建一个“Scrum of Scrums（SoS）”

一个跨团队协作的Scrum团队

由Scrum Master们组成的团队本身就是一个Scrum团队

负责在每个冲刺结束时从所有参与的Scrum团队中集成得到完整的潜在可交付产品增量

实时响应各参与团队提出的障碍

作为一个发布团队

能够直接向客户交付价值

（Sacled Daily Scrum），
简称：SDS

一个跨团队的Scrum每日例会

每个团队都会派代表参加SDS

团队中的任何人或者任意数量的人都有可能参加

通常是Scrum Master参加

目的

协调团队，以及消除团队交付价值的障碍

SDS事件

时间被限制在15分钟以内

每个团队必须派代表参加会议

是一个团队代表们解决三个简单问题的讨论会

本团队有什么障碍会妨碍其他团队完成其冲刺目标

或者影响即将到来的发布版本

本团队是否正在做任何会妨碍其他团队完成其冲刺目标的事情？

或者影响即将到来的发布版本

我们是否发现了任何新的跨团队依赖，或者发现了现存依赖的解决方法？

SoS必须具备所有必需的技能

产品负责人的代理人

负责解决优先级问题

经验丰富的架构师、QA负责人

其他具有操作技能的人们

刚开始启动Scrum@Scale时

不具备支撑持续部署的基础设施

不得不

建立一个“集成团队”或“发布团队”

克服工程技术缺陷而产生的额外工作

鼓励SoS

积极地解决集成和部署障碍

打造实现超高生产率所需的环境

例如亚马逊有3300个Scrum团队，平均每秒部署一次以上

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

对团队们联合产出的发布版本负责

职责

制定组织可见的障碍待办列表

消除各个团队无法自行解决的障碍

对障碍进行优先级排序，并特别关注跨团队依赖和待办列表的分布情况

提升SoS的效能

与产品负责人们密切协作，在每个冲刺中至少部署一个潜在可发布产品增量

结合产品负责人的发布规划，协调各个团队的部署工作

扩展SOS

Scrum of Scrum of Scrums（SoSoS）

多个SoS协作

基于组织和实施团队的规模

交付非常复杂的产品可能需要多个SoS协作

在多个Scrum of Scrum之上

建立一个Scrum of Scrum of Scrums（SoSoS）

Scrum团队群的一个有机模式

可以无限扩展

每个SoSoS应该有自己的SoSoS Master（缩写：SoSoM

优点

减少组织内的沟通路径数

使复杂度得到封装

协作方式

完全相同

SoSoS与SoS

SoS与单个Scrum团队

子主题

4或5人是最佳的协作规模

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

决策层行动小组

Executive Action Team ，
缩写为EAT

针对整个敏捷组织的SoS

各个SoS不能消除的障碍，最终会反馈到EAT

组成

在行政上和财务上得到充分授权的个体

也需要一个PO和一个SM

职能

协调多个SoS（或多个SoSoS）

最好能像Scrum团队一样每天碰面

个冲刺他们必须至少碰面一次

有一个透明的待办列表

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

子主题

EAT的待办列表和职责

组织变革待办列表

经过优先级排序的待完成敏捷事项清单

跟进执行落地情况

例如

原先组织中存在传统的产品开发生命周期，
那么就必须创建、实施和支持一个
全新的敏捷产品开发生命周期

职责
对组织内的Scrum质量负责

在组织范围内为参考模型创建一个敏捷运作系统，
包括企业运作的规则、规程和指南，
以使敏捷能得以实施

度量和改进组织中的Scrum质量

在组织内打造业务敏捷性能力

为Scrum专业人员创建一个持续学习中心

支持探索新的工作方式

MetaScrum
产品负责人组织

由PO和关键干系人们组成的团队

以类似SoS的形式把PO们也组织起来

建立和支持一个相应的产品负责人组织

SCRUM MASTER
组织的产出/成果

SM组织

SoS

SoSoS

EAT

协同完成Scrum Master循环中的其他组件

持续改进

消除障碍

跨团队协调和部署

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

识别障碍并把它们转化为
组织改进的机会

维护一个安全和结构化的环境，
以对障碍进行优先级排序，
消除障碍并验证由此带来的改进

确保组织中的可见性，
以促进变革

跨团队协调的目标

协调跨多个相关团队的类似过程

管理跨团队依赖，
确保它们不会转变为障碍

维护团队规范和准则的一致性，
以确保输出一致

部署的目标

向客户持续地交付有价值的成品

把来自不同团队的工作成果集成为一个无缝的产品

确保客户体验的高质量

产品负责人循环

协调“做什么”– MetaScrum

“MetaScrum”的团队

一个SoS需要一份唯一的产品待办列表作为输入

负责整合这份产品待办列表的这些产品负责人自身构成一个称为“MetaScrum”的团队

每个SoS都有一个相关的MetaScrum

将所有团队的优先级沿着一条路径进行排列，以便整合产品待办列表

通过与干系人达成一致来获得他们对整合后产品待办列表的支持

执行多团队的当前发布的产品待办列表精化

每个团队的PO（或者PO代理人）都必须参加。

这个事件是一个供领导层、干系人或其他客户表达他们喜好的讨论会

MetaScrum的主要职能

为产品规划一个总体愿景并使其对组织可见

与关键干系人达成一致，以确保其支持产品待办列表的实施

生成一份唯一的、经过优先级排序的产品待办列表，确保避免重复劳动

创建一个统一的“完成的定义”，应用于SoS中的所有团队

消除SoS提出的依赖

生成已整合的发布规划

决定采用哪些度量指标来洞察产品，并执行监控

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

首席产品负责人

负责协调本MetaScrum的所有团队

整合出一份唯一的产品待办列表

CPO与各个团队的产品负责人协调优先级顺序

职责

规划整个产品的战略愿景

创建一份唯一的、经过优先级排序的产品待办列表，包括所有团队要交付的价值

与单个团队PO的产品待办列表项相比，这些产品待办列表项可能是更大的故事

与相关的SoSM密切协作，使MetaScrum团队生成的发布规划得到高效部署

监控客户的产品反馈，并对产品待办列表进行相应的调整

扩展METASCRUM

每个组织自行定义扩展单位术语和扩展头衔

当PO团队扩大时，我们选择添加一个额外的“首席（Chief）”修饰词到其头衔中

理想规模的Scrum团队和理想规模的MetaScrum

子主题

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

MetaScrum

使我们设计一个产品负责人网络

能与相关的SoS一起无限扩展

决策层MetaScrum
（Executive MetaScrum ，
缩写为EMS）

针对整个敏捷组织的MetaScrum

拥有组织愿景

为整个集体设置战略优先级

所有团队都围绕共同目标调整一致

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

子主题

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

PO组织

各个MetaScrum

CPO

EMS

协同实现产品负责人循环的组件

战略愿景

待办列表优先级排序

待办列表分解&精化

发布规划

规划战略愿景的目标

使整个组织沿着一条共享的前进路径清晰地调整一致

令人信服地表明组织存在的意义

描述组织将如何撬动关键资产以支持其使命

持续地更新，以应对快速变化的市场环境

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

将待交付的产品、特性和服务，
确定一个清晰的优先级顺序

在待办列表的排序中，
要反映出价值创造、风险缓解和内部依赖

在待办列表分解和精化前，
先在整个敏捷组织层面进行高级事项的优先级排序

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

把复杂的项目和产品分解成独立的功能单元，
这些单元应当能由单个团队在一个冲刺内完成

捕获和提炼浮现出的需求和客户反馈

确保所有的待办列表项都是真地“就绪”，
以便能够被各个团队领取

发布规划的目标

预报关键特性和能力的交付

与干系人沟通交付预期

必要时更新优先级

理解反馈

反馈组件

PO与SM循环的第二个交点

产品反馈

调整产品待办列表来驱动持续改进

发布反馈

调整发布机制来驱动持续改进

获取和分析反馈的目标

验证我们的假设

理解客户如何使用产品以及如何与产品交互

捕获对新特性和新功能的创意

定义现有功能的改进点

更新产品/项目的进展，提炼发布规划并与干系人达成一致

识别对部署方式和部署机制的改进点

度量和透明

彻底的透明

Scrum能最佳运作的关键

出现在拥抱Scrum价值观的组织中

赋予组织真诚地评估其工作进展

检视和改变产品及过程使之更适应的能力

Scrum的经验主义本质的根基

度量

SM循环和PO循环都需要

度量指标

分别由SM组织和PO组织决定

可能是唯一的

不需要任何特定的度量指标集

组织最低程度的度量

生产率

例如，每冲刺的交付可用产品量的变值

价值交付

例如，每单位团队工作量的商业价值

质量

例如，缺陷率或服务宕机时间

可持续性

例如，团队的幸福感

度量和透明的目标

向所有决策者（包括团队成员）
提供适度的背景信息，
以便做出正确的决策

尽可能缩短反馈周期，
以避免矫枉过正

要尽可能地减少团队、
干系人或领导的额外投入

关于组织设计的一些说明

Scrum@Sacle的“可自由扩展（Sacle-Free）”的自然属性

基于组件的方式设计组织架构

根据市场需要进行团队的重构和再平衡

通过开发外包，
一些企业获得了其它方式无法获得的人才，
并按需进行扩张和雇用

避免

过长的滞后时间

妥协的沟通

低劣的质量

在组织规模和全球分布上都可以线性扩展

子主题

专家组成的虚拟团队

知识团队

基础设施团队代表

每个专业设置一位PO

专家人数太少而不可能为每个团队都配备

作为一个小组与Scrum团队们通过服务等级协议进行协作

所有对某专业的服务请求都必须流经该专业的PO

由PO负责把服务请求转化为透明的、经过优先级排序的待办列表

这些团队并不是所有成员都坐在一起的集中封闭式团队

表示为空心五边形的原因

他们的团队成员都坐在实际的Scrum团队中，但他们自身组成了这个虚拟Scrum团队

实现在组织中散播待办列表和过程改进

独立的Scrum团队

客户关系

法律/合规

人力运营

其他所有团队可能都会依赖他们

对EAT和EMS的表示

显示为重叠

有2位成员在两个团队中都存在

非常小的组织或实施

EAT和EMS可以由完全相同的一组成员组成

结束语

Scrum@Scale

为提高生产率而设计

使整个组织在改善质量和显著改善工作环境的情况下实现事半功倍

在大型组织中恰当地实施本框架

可以降低产品和服务的成本

提高质量和促进创新

能让组织贯彻和执行Scrum而设计

所有的团队

领导

人力资源

法律

咨询

培训

产品

服务

实施相同风格的Scrum

精简和强化组织

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

参考链接

https://www.scrumcn.com/agile/scrumatscale.html

英文：

https://www.scrumatscale.com/scrum-at-scale-guide-read-online/

SCRUM@SCALE指南概述

目的

优化组织整体战略

高效协调多团队的新生态系统

采用可自由扩展的架构（Scale-Free）

建立"最小可行的管理机构”

独立实施Scrum@Scale

包含

构成Scrum @ Scale框架的组件定义

扩展角色

扩展事件

组织工件

把它们组织在一起的规则

Scrum@Scale

Jeff Sutherland博士

基于Scrum

基本原则

复杂适应系统理论

博弈论

面向对象技术

为什么需要SCRUM@SCALE

Scrum是为使单个团队而设计

组织的扩张以及Scrum团队数量的增长，团队们的最佳产出（可工作的产品）以及团队速率在开始下降

实现组织的线性可扩展性

可自由扩展的架构（Scale-Free）

能有效协调多团队的框架

基于其独特的需求

被组织成员群体接受的可持续变化节奏

有机地扩展

覆盖

所有的部门、产品和服务

应用于

行业、政府或学术的各类组织机构的多个领域

SCRUM@SCALE的定义

Scrum

一个框架

解决复杂的自适应难题

高效并创造性地交付最高可能价值的产品

《Scrum指南》

一套最小特征集

彻底的透明

促使检视和适应

促进创新

提升绩效和团队的幸福感

Scrum@Scale

定义

一个框架

一个用于扩展Scrum的框架

使用Scrum来扩展Scrum

通过

SoS（Scrum of Scrums）

MetaScrum

协调的Scrum团队们组成

遵从《Scrum指南》运作的多个Scrum团队组成的网络组织

解决复杂的自适应难题

创造性地交付最高可能价值的产品

特点

轻量的

最小可行的管理机构

易于理解的

由且仅由单个或多个Scrum团队组成

难以精通的

需要实施全新的运作模式

允许组织自行定制其转型策略和实施方式

转型工作

聚焦于其认为最有价值或者最需要变革的区域

再向其他区域推进

关注

从职责上分离“做什么”和“怎么做”

两个循环

Scrum Master循环（负责“怎么做”）

产品负责人循环（负责“做什么”）

产生

能协调多个团队往一处使劲的强有力框架

明确权力和责任

消除会妨碍团队们实现最佳生产率的浪费性组织冲突

“产品”

可以是硬件、软件、复杂集成系统、事务过程、服务等等

取决于Scrum团队们所处的领域

SCRUM@SCALE框架的组件

子主题