敏捷团队运用“Scrum of Scrums”进行协调与合作

当项目或产品开发过程中涉及到多支团队的时候，可以使用 Scrum of Scrums 来扩展每日立会——其用途在于，帮助敏捷团队面向其他团队协调与合作其工作。针对 Scrum of Scrums，许多作者分享了各自的看法以及使用的经验。

Charles Bradley 撰写了一篇关于拯救备受争议的 Scrum of Scrums 的博客文章，在其中描绘了对于同一个产品开发中共事的多支团队，Scrum of Scrums 如何帮助他们（重新）规划并协调开发工作：

我相信并且亲身体验过专注于开发团队的方法：在团队层面，遵从 Scrum 背后的原则，遵从每日 Scrum 实践的原则，最终以更快的速度向客户交付了更多的价值。在我的经验中，针对开发团队并由其进行实践的高效的 Scrum of Scrums，将极大的提升开发团队的自组织技能，更快速地消除阻碍，产出更高质量的产品，并在更短的时间内交付更高的价值。

对于 Scrum of Scrums，Charles 在他的博客文章中收集了来自 Ken Schwaber、Mike Cohn、Craig Larman、Bas Vodde 以及 Jesse Houwing 等人的观点。他的结论是，Scrum of Scrums 应该专注于帮助开发团队的成员们按照自组织的方式协调与合作，而不应该成为 Scrum Master 们的状态会议。

在我辅导 Scrum 团队的时候，特意强调了在扩展 Scrum 时要遵从其基本原则。我鼓励 Scrum Master 们（如果他们参加 Scrum of Scrums 的话）站在开发团队成员的“圈子之外”，并避免与开发团队成员进行目光接触——因为后者正在进行协作。我相信基于原则的扩展，因此针对各支开发团队的每日 Scrum，我在面向 Scrum Master 们进行培训时也贯彻了相同的技术。我希望开发团队成员能够得到授权，在其协调与合作的努力中真正进行自组织。是的，当然我也会指导 Scrum Master 成为“仆人式领袖”，以便根据需要发挥作用——但我还鼓励他们，当开发团队自身能够拥有高效的 Scrum of Scrum 时，尽快退居幕后。

在另一篇题为有效的 Scrum 产品组织机构模式（第二部分）的博客文章中，Robert Galen 为大型产品开发机构提供了一套解决方案，用来将团队的 Scrum of Scrums 与团队栖身的产品开发机构关联在一起。在他看来，可以从三个层面建立起这样的关联：

1. 在最低层：每支团队都拥有一位产品所有者；他们结合各自团队的能力，使用产品待办事项列表来推动其工作。
2. 在 Scrum of Scrums 的层面：产品所有者们需要进行合作。这种情况下，往往存在一个“产品所有者领袖”的角色，由产品所有者之一担任。此时，他负责管理横跨各个待办事项列表的聚合视图。
3. 而在 Scrum of Scrums of Scrums 层面，一般会有一位“首席”或“超级”产品所有者，负责将更高层级的业务路线图和交付承诺，与执行它们的团队联系在一起。他们往往跟踪并维护了解到的承诺与 Scrum 交付团队的实际速度之间的平衡。

从多个层面建立起 Scrum 团队和产品所有者之间的关联，将有助于在大型企业中采用敏捷：

这一模式的精髓是组织机构的转型。高效的产品组织机构将自身的构造，与其技术团队现在如何交付产品重新关联。同时，他们将学习如何构成、解构和重构待办事项列表，从而通过其 Scrum 团队推动工作。

Giuseppe De Simone 撰写了一篇关于“Scrum of Scrums”迷思的文章，在其中提到了一个关于扩展敏捷的神话：

当需要把 Scrum 推广到更多的团队时，你可以使用 Scrum of Scrums 来处理团队之间的依赖与协调。

对于 Scrum 团队如何减少团队之间对协调的需求，他列出了一些可以做的事情：

实际上，在 Scrum 中对依赖的处理，是通过切实消除或至少最小化依赖的方式来实现的。这项任务可以在许多维度来完成，而下面是你不应该错过的五项关键点：

1. 首先，开发团队必须具备跨功能的特点，这意味着在一个可能发布的产品增量中，对于改造产品待办事项列表中的条目，团队拥有所需的全部能力。可以引入集体代码所有制作为补充：让每个人都能够接触到任何一行代码，以便在 Sprint 结束时交付产品增量；否则你将会让许多外部依赖束缚住你的团队。
2. 待办事项列表中的条目应该采用端到端用户故事的形式，从前端到后端将系统切分为各个层面，以生成可能发布的功能片：基于组件的开发产品，而不是糟糕的依赖。
3. 用户故事应该遵循“INVEST”模式（Independent、Negotiable、Valuable、Estimable、Small、Testable：独立、可协商、有价值、可估算、小尺寸、可测试），其中，I 代表着独立，它将有助于简化针对用户故事开展工作。
4. 在扩展后的 Scrum 方法中，产品所有者团队开发唯一的产品待办事项列表，为所有开发团队提供输入，并确保各支开发团队尽可能独立，从而能够快速前进并减少相互之间需要协调的部分。
5. 各支 Scrum 团队在一起制定计划，从而尽早探明剩余的依赖。

通过让 Scrum 团队执行上述事项，进行 Scrum of Scrums 的需求及其目的发生了变化：

这并不是让 Scrum Master 们汇报某些类型状态的会议，而是为遇到问题的人提供了一个抛出问题、获得来自其他团队的快速帮助的可能。

Scrum of Scrums 并不意味着无数次的协调结构，相反它更多的是一种紧急程序——当某支团队已经或将要把某些事情放到其他团队身上的时候启用。

在博客文章 Scrum of Scrums——沟通情况的测温表中，Morgan Ahlström 分享了使用 Scrum of Scrums 的经验。他所描述的项目涉及了来自三个国家的七支团队，该项目定期举行 Scrum of Scrums：

所有的 Scrum Masters 和项目经理每周举行三次电话会议，Scrum Master 们依次进行状态报告（！）并对自己遇到的麻烦发出抱怨。一些 Scrum Master 找上了我，咨询是否应该减少会议频率，因为“没有说什么新东西。每次会议上都会抛出相同的问题。”

看起来，这些团队没能够在每次会议间隔的时间段中解决这些问题。Morgan 建议 Scrum Master 们开始记录下问题，并着手研究它们，而不是在 Scrum of Scrums 上进行抱怨。他还为 Scrum Master 们安排了当面会晤的机会，以便使大家更好地了解彼此：

我设法筹措足够的资金，使所有 Scrum Master 汇聚一堂，进行回顾会议及其他研讨会。让大家彼此认识，为我们带来了美好的一天，然而这还不够。在这一天结束的时候，我问房间里的每个人，是否把其他人的联系方式存入了手机通信录中的快速联系人，然而可怕的回答是没有任何人把别人的手机号码存入自己的电话中。解决这个问题很容易，然而问题在于，让大家都使用电话号码。

在这天之后，我开始要求每个 Scrum Master 都以每天一次的频率，给其他所有人打电话。无论他们是否有问题需要讨论，都应该进行一次至少社交性质的通话，以了解其他人在做什么。这一举措并未立即生效；大部分人都想着他们回去以后不会这么干，然而我在一对一环节继续向他们提出了这一要求。

Morgan 注意到，自从 Scrum Master 们在相互之间建立起关系之后，更多的问题正在得到逐步解决：

（……自此之后）Scrum of Scrums 上出现的问题越来越少。相反人们开始进行社交性讨论，并谈论已解决的问题。（……）项目中依旧有大量的问题存在，但是现在他们开始在 Scrum of Scrums 之外解决这些问题。这些团队（或至少其 Scrum Master 们）已经对其他人有所关心。甚至有一支团队派遣了团队中的部分开发者，到另一支团队身处的国家中，帮助他们解决问题——甚至后者还没有鼓起勇气寻求外部帮助。

在一个多月的时间里，我们的会议就从不能够帮忙协调或解决任何问题，转变为没有问题需要协调和解决。这让我注意到每日立会和 Scrum of Scrums 本身或许并不是真正的解决方案，相反它们揭示了我们与其他团队（在会议以外）交流的好坏。

那么各位读者，你是否也采用了 Scrum of Scrums？它如何帮助你的团队实现协调与合作？

查看英文原文： Using Scrum of Scrums with Agile Teams to Coordinate and Collaborate