根据2021年《中国企业敏捷实践白皮书》调研显示，国内企业首选的大规模敏捷框架是 Scrum of Scrums。
通过增加更多的人来解决问题只会使问题变得更加困难，但如果你找到一种方法，能让它随着你的扩张成长而变得更有效，那么这就是规模效应。
几十年来，Scrum为许多团队和企业的成长提供了基础。然而，当面对更宽泛的业务场景，需要将 Scrum 从单个团队应用到多团队时，Scrum 指南并不能很好的满足需求。为了实现这一点，Scrum of Scrums 技术（也称为 SoS）应运而生。
一、Scrum of Scrums 的历史
Scrum of Scrums 方法论于 1996 年由 Scrum 框架的两位先驱 Jeff Sutherland 和 Ken Schwaber 首次提出并实施。当时，Sutherland 和 Schwaber 需要一种方法来协调八个业务部门，每个业务部门有多个产品线，他们需要让各个团队实现信息的相互同步。
为此他们尝试了一种新的方式来扩展 Scrum，这次尝试极大的启发了 Sutherland ，他在 2001 年发表了一篇题为《敏捷规模化：通过5个跨团队的敏捷实践重新定义Scrum》的文章，其中首次公开提到了 Scrum of Scrums。
从那时起，Scrum of Scrums 作为一种与规模化敏捷相关的实践方法越来越受大家欢迎，并收录在《Scrum@Scale 指南》。由于 Scrum of Scrums 提供了一个帮助团队扩展的结构，所以它被不少其他规模化敏捷框架学习和引用。
二、什么是 Scrum of Scrums？
Scrum of Scrums 是一种规模化的敏捷方法，具备透明、回顾、改进等特点，它为需要协同工作以开发交付复杂解决方案的多个团队提供了一种连接方法。当所有 Scrum 团队成员都朝着一个目标努力、互相信任、尊重时，Scrum of Scrums 会更容易成功。
Scrum of Scrums 的成功实施和团队规模息息相关。Hackman 和 Vidmar 的研究表明，理论上 4.6 人是“最完美的单团队规模”，太小或太大的团队可能会难以交付复杂的产品。
记住《The Mythical Man-Month》一书中的 Brooks 定律：为后期的软件项目增加人力通常会使交付变得更晚。
团队规模越大，团队成员之间的沟通渠道就越多，信任和共同目标就越难维持。
因此，将一个非常大的团队分成两或三个较小的团队可以帮助降低沟通成本，并有利于按计划交付。团队拆分时需要注意，必须考虑到平衡团队成员之间的技能，定义清楚团队的目标、边界，并仔细分解工作职责。这个过程中可能会出现新瓶颈影响交付速度。当这种情况出现，团队需要重点做好迭代回顾和优先级排序，这将有利于解决这些问题。
三、Scrum of Scrums 的目的
当创建多个团队以实现共同目标时，会需要频繁进行沟通和协调，这一点催生了对 Scrum of Scrums 的需求。
Scrum of Scrums 可以理解为一个虚拟的团队，它由各个交付团队的代表组成，与传统的组织结构或基于项目的团队相比，Scrum of Scrums 创造的团队结构简化了沟通路径，能够更好地协调多个独立小团队。使用 Scrum of Scrums 的团队不仅可以协调交付，还可以确保在每个迭代结束时获得一个完全集成的交付产品。因此，Scrum of Scrums 是能够提供更高价值的发布团队。
大型企业通常使用这种方法作为规模化敏捷和组织大型复杂产品交付团队的第一步实践。
四、Scrum of Scrums ——规模化的结构
新成立的 Scrum of Scrums 团队通常采用相同的敏捷实践，参与相同的活动，并具相同的角色。但是为了在每个迭代结束时高质量地交付可集成的、可使用的产品，可能需要架构师或质量保证负责人这类额外的团队角色。
例如，增加首席产品负责人角色，负责监督产品负责人团队并指导总体产品愿景，此角色不需要由专职人员担任，因为该角色一定程度具有与产品负责人（Product Owner）相同的工作职责，差异只体现在管理规模上。
另一个新角色是 Scrum of Scrum Master，该角色专注于所有团队的工作进度和待办列表，保证工作优先级并清除障碍，不断提高 Scrum of Scrums 的有效性。
这些新角色会通过 15 分钟的每日例会来调整、改进和清除障碍。每个团队的代表或产品负责人应该集中讨论团队的进度、达成目标的风险或对其他团队的依赖，然后分享其他团队可以利用的改进方法。
五、总结
Scrum of Scrums 是规模化敏捷的关键方法，正在被越来越广泛的使用。除此以外，规模化敏捷的一个重要先决条件是：正确组织团队，并为团队提供足够的时间和空间，让团队能够不断的成长出最佳实践。
当团队准备应用 SoS 时，以下是一些可用的注意事项：
- 将规模化的每日站会保持在 15 分钟，反映整体团队的工作进度
- 在最后一个敏捷团队的每日站会后，进行 15 分钟的规模化每日站会
- 为 Scrum of Scrums 制定统一的标准和规则
- 明确规模化团队和敏捷团队对于完成的定义
- 跟踪团队被问题或障碍阻塞的时间长度
- 跟踪按时开始和完成的每日站会次数
- 专注于交付具有依赖关系的故事，以降低风险并支持其他团队
- 跟踪和可视化演示会议之前的工作进度
事实上，没有一个通用的正确方法帮助所有团队成功实现规模化敏捷，但是，许多企业和团队都在使用规模化敏捷的理论框架来优化他们自己的工作流程，并在组织团队和发展团队文化方面取得了巨大成功。
