不采用 Scrum of Scrums 来扩展 Scrum

Scrum 可以有效地提高开发团队成员之间的交流，但如何把这种高带宽的交流扩展到团队之间——尤其是在大型组织里面，仍然是研究和讨论的活跃领域。 Will Read 提出了一种网状网络方法，替代流行的 Scrum-of-Scrums 会议，以求达到这一目标。

Will 指出，Scrum of Scrums 创建了一个层次的、树形的交流网络。人们是系统中信息的创造者和消费者，也是树上的叶子节点。向一个中央控制点提供并传播信息，这种结构相当 有用。然而这未必是协调开发者工作的最好方式。每个开发者需要知道的那类信息可能无法有效地沿树传播。

Jim 需要知道新的日志 API，他就不必自己重写一份了。Bob 需要知道 Sue 传递给她函数的参数有问题，因为 NULL 是不允许的。Dave 需要知道他得 为 Linux 服务器升级最新的 Java 虚拟机，以修复 Mark 发现的一个 bug。而新员工 Mindy 需要搞明白从哪儿下载第三方的 DLL。

这种类型的信息在网状的网络中更容易流转，个人和团队更好地根据需要进行交流。然后问题就变成了企业如何创建网状网络，以提高这种信息的流转？混合 出席每日站立会议上是一个方法。如果两个或以上的团队编写相同的代码，或者相互之间依赖，那么允许成员参加相关团队的站立会议就很有意义。Will 还提出 了一些其它的方法：

• 提高并促进网络中的自我管理
• 给不同的团队分配有关联的功能，以提高网间的联系
• 安排很少一起工作的团队在工作之余进行交流
• 识别自然形成的交流中心，并提高中心之间的交流
• 考虑联系紧密的团队之间交换成员

Will 这样描述了这种交流网络的好处：

通过网状网络，公司可以产生更适合的交流结构，传播知识更可靠，交流失败的风险更低，并可扩展到任意大小的公司，解决带宽有限的问题。最棒的是，它符合敏捷中自组织的原则，可以消除浪费，增强业务。

如上所述，网状网络的目的是提高开发者之间的信息交流，不需向管理层汇报状态。但如果交流集中于状态、进度和优先级，尽管其所需的带宽会大大减少，树仍然是更可取的方法。

你的组织里 Scrum 团队之间如何交流？交流是否有效？能够更好吗？欢迎留言与社区分享。

查看英文原文： Scaling Scrum Without the Scrum of Scrums