Scrum of Scrums：如何高效协调多个团队进行线性敏捷规模化

Scrum of Scrums 是主流的敏捷规模化方法之一，被用于在复杂敏捷项目组织中协调多个项目团队，并能够直观地进行线性规模化。

Scrum框架的作者Jeff Southerland和Ken Schwaber于1996年在IDX Systems工作时首次使用了Scrum of Scrums。当时他们需要一种方法来协调八个事业部，每个事业部有多个产品线，而Scrum of Scrums 使他们能够有效地做到这一点。2001年，他们发表了一篇文章：《敏捷可以扩展：发明和重塑SCRUM1》，根据他们的经验，提出如何用Scrum of Scrums的方法将Scrum应用于大型组织之中。2011年，他们发表了Scrum@Scale指南2，这是一个更全面、规模更大的敏捷框架，用于在大型组织中实现Scrum，Scrum of Scrums 被整合于其中，成为规模化的技术之一。

从此以后，Scrum of Scrums 成为管理多个Scrum团队和线性规模化最流行的敏捷规模化框架之一。根据Digital.ai的一项调查，截至2020年，Scrum of Scrums 是第二大最受欢迎的规模化框架。

从核心来说，Scrum of Scrums 是一个会议，来自每个团队的代表将在这个会议里会面和讨论，各个代表可以协调项目、共享信息和解决依赖工作的关系。代表的数量和会议的频率取决于组织自身，只要它能够实现了Scrum of Scrums 的目的。

Scrum of Scrums 的一个关键点是将一个大团队拆分为多个小团队。大型团队通常会降低团队的生产力和绩效，因为信息的交流和沟通是一项挑战，很难及时让每个人都了解最新的变化，也很难确保每个人都在同一个页面上。这可能会导致误解、错过最后期限，甚至导致代码中的错误。

这个Scrum@Scale根据1970年哈佛大学的研究，该指南建议团队中有4到5人，建议最佳团队规模为4.6人。然而，关于最佳团队人数的研究还有很多。例如，SCRUM：《保持团队规模在7以下！3》。根据SCRUM的研究：《保持团队规模在7以下！3》- Scrum Inc. 解释了Scrum团队中少于10人的证据，这在Scrum指南中有所建议。报告还说，规模较小的球队表现还要更好一点，但是差异很小。根据这些研究，5到10人似乎是团队的最佳规模，我们应该根据业务环境进行调整。

• Scrum of Scrums 的关键点是将大团队拆分为多个小团队，因为大团队的生产力和绩效会下降。

• 有几项研究显示了团队的最佳规模，这些研究显示的数字略有不同。

• 5到10之间似乎是最佳数字。但需要根据业务环境进行调整。

在Scrum of Scrums 期间，来自各个Scrum团队的代表们同样地在Scrum Master的引导下讨论了几个与通常的Scrum相似的主题。然而，这些主题可以根据您的项目环境来进行调整，因为没有事实上的标准。比如，我们可以提问来帮助我们：

• 自上次Scrum of Scrums 会议以来，团队完成了什么？

• 在下一次Scrum of Scrums 会议之前，团队将做什么？

• 是否存在阻碍团队完成工作的挑战？

• 您的团队正在进行的任何任务是否可能阻碍另一个团队的进度？

Scrum of Scrums 的频率取决于项目，尽管Scrum@Scale指南建议，在每个团队的每日站会之后，来自各团队的代表又用15分钟来进行规模化敏捷的每日站会（Scaled Daily Scrum，SDS）。下表描述了如何根据我的研究进行Scrum of Scrums 。然而，您必须自定义它，因为似乎没有Scrum of Scrums 官方文档来进行指导。

首席产品负责人（CPO）是代表跨团队的总产品负责人的角色。CPO负责监督产品整体，确定优先级，并解决团队之间的依赖关系。这个角色不需要由一个专职的人来担任，而且这个角色应该与产品负责人具有相同的责任。CPO通常在产品管理方面更有经验，并对业务领域有深入的了解。此外，如果其他产品负责人不熟悉产品管理和业务知识，CPO可以对他们进行指导。

SoS Master的团队是由每个Scrum团队中的Scrum Master所组建而成，对于这个SoS Master团队可以有一个SoS Master的角色（SoSM）。SoSM负责引导Scrum of Scrums，解决依赖关系，协助CPT决策，并消除障碍。SoSM尽可能地提高Scrum的绩效，在效能提升方面发挥着关键作用，因为会议的有效性是核心。SoSM通常在Scrum方面更有经验，并且需要强大的领导技能。这个角色不需要由一个专职的人来执行，和CPO类似，这个角色应该和Scrum Master有同样的责任。

问1：Scrum of Scrums是否只是为了管理一个产品而设计的？

答1：它可以用于多种产品。当Jeff和Ken第一次尝试Scrum of Scrums时，他们正在努力协调八个事业部，每个事业部有多个产品线。根据经验，他们得出结论，Scrum可以与Scrum of Scrums进行规模化的扩展。

问2：我需要制作一个通用的产品待办列表吗？

答2：不一定，这是因为Scrum of Scrums只是一个协调会议。然而，如果有必要，你可以建立一个列表。但是，如果你在运作更全面的敏捷框架，Scrum@Scale，那么就需要一个共同的的产品待办事项列表。

问3：因为我们没有足够的Scrum Master，一个Scrum Master能管理多个团队吗？

答3：可以的。只要能实现SoS Master的目的，一个Scrum Master就可以管理多个团队。例如，当我在一个预算不足的项目上工作时，肯定需要一个Scrum Master管理多个项目。

• Scrum of Scrums 是规模化项目的最佳实践之一。它是由Scrum的作者根据他们的实践经验发明的。

• 一个Scrum团队应该很小，在5到10之间，因为在一个大团队中，团队的绩效和生产力会下降。

• 建议在每个团队的每日Scrum结束后的15分钟内进行SoS的每日站会。

• CPT负责跨团队监督产品，确定优先级并解决依赖关系。这个角色不需要由一个专职的人来执行，而且这个角色应该与产品所有者具有相同的责任。

• SoS Master是代表每个团队的Scrum Masters的角色。SoSM负责引导Scrum of Scrums，解决依赖关系，协助CPT决策，并消除障碍。

注解：

1. 《敏捷可以扩展：发明和重塑SCRUM*》：Agile Can Scale: Inventing and Reinventing SCRUM

2. Scrum@Scale指南：the Scrum@Scale guide

3. 《保持团队规模在7以下！3》：SCRUM: Keep Team Size Under 7!