Scrum of Scrums 的从诞生起就是一种为了处理多Scrum团队项目的相互依赖的复杂性的机制。每天，在每个团队进行完每日站会后，由每个团队派出的代表来组成一个“Scrum of Scrums”会议。在这个会议中，每个团队的代表向大家报告他的团队 昨天做了什么有可能影响其它团队的工作，以及明天有可能做什么有可能也会影响其它团队的工作。他们主要会集中在讲问题上面。就跟每个团队内的每日站会一样，只是在一个更高的层面上。
Scrum of Scrums 的目的是为了给不能在一起工作并进行随时沟通的团队提供透明性。当然，很多时候这种办法会失效。因为有些团队的代表无法随时记住，或者完美预测 ，或者清晰表述出，他自己的团队有可能会影响其它团队的问题。
就像工程方法，构建，测试平台等在这些年有了很多改善一样，我也不断增加对Scrum of Scrums的推荐。今天，我们会要求所有的Scrum团队能在Sprint结束时，在Sprint评审会议上展示单一的，集成的，经过完整测试的功能。这样能确保在真正的产品过程中的完全透明性，并且不需要人们去进行“逻辑性”的评测来判断每个单块的增量加起来 等于一个完整的增量。如果团队们打算做到这样，他们会发现如果要等到最后一天才集成会是一个很糟糕和过时的想法。他们会开始进行集成构建和测试，至少一周一次。直到后来他们用每日构建甚至很多时候是持续构建和测试来武装起来。这时候， Scrum of Scrums 就要发挥作用了。没人需要去纠结于记住或者预测。相反，他们有明确和直接的问题进行讨论，比如：“我想我已经告诉过你我们会去动这一块代码，你们现在去做这件事会导致构建失败”。
这是一件复杂的事情，它需要更多的基础条件和技巧。然而，它会阻止“未完成工作”的积聚。当然，未完成工作通常会 在依赖没有被完整考虑时出现。如果它们一直出现直到最后发布阶段，最后的几个Sprint会变成一个无法被预见的“进行稳定的阶段”。
如果你真想做到“精益”，增加一条要求：只要集成构建或者集成测试失败，任何开发人员不允许做任何工作直到错误被修复。为什么？因为这时开发人员做的任何工作都可能是基于一个不可靠的基础，而且是不可能预测接下来需要花多长时间来修复它们的。
原文地址：http://kenschwaber.wordpress.com/2010/07/27/the-evolution-and-importance-of-the-scrum-of-scrums/
