译者序：在规模化敏捷中常强调的有效沟通和交付对齐。Scrum of Scrums是一种最早的规模化敏捷技术，简单且有效，用于集成多个（建议不超过3-9个）在同一产品上工作的Scrum团队的工作。Scrum of Scrums确保团队之间有效沟通，以使每个团队的软件输出与其他团队的输出很好地集成在一起并交付客户，尤其是在工作重叠或时间顺序很重要的地方；同时，也是为了共同讨论并决策。最直观的活动就是SoS会议，由各Scrum团队中派出主要代表参加。总体目标是使团队工作保持顺畅，并使总体交付成果保持在正常状态。通常组织将这种方法用于扩展敏捷性和组织大型复杂产品交付的第一步，然后在酌情考虑采用更成熟的规模化敏捷框架。
Jeff Sutherland说过“我使用过的Scrum of Scrums负责在Sprint结束时将所有团队的可工作的软件按完成定义交付，或者在Sprint期间发布。”
正文:
Scrum团队正在与多个开发团队共同开发一个产品。开发团队需要协调依赖事项和分担工作。各个团队中未解决的依赖事项是所有团队的共同挑战。
当多个团队彼此独立工作时，他们倾向于仅专注于自己的关注点，却看不到任何共同目标。
组织可能会错误地认为，敏捷只能在一个团队的规模下发挥作用，转而采用命令与控制的方法。但在这种情况下，复杂性不减反增。分层控制会增加延迟，从而降低团队以及更大规模的组织对业务和技术变更的响应能力。
Scrum团队可以将问题分解为多个小部分，以便每个开发团队都可以在部分可交付成果上单独工作。然而，泰勒主义的科学管理原理认为，在复杂的环境中，想通过优化局部来优化全局是行不通的（《国际运营与生产管理杂志》）。工作与工作之间会出现意想不到的依赖性，这会减慢交付速度并降低组织对变更做出响应的能力。
独立的多个团队可以合并成一个统一的团队，但是沟通和协调的开销将成倍增长，从而导致非正式的子群体出现。这些子群体可能会按照职能划分边界，这意味着它们不再那么跨职能了。
多个团队可以向共同的经理或管理职能报告，以解决依赖性，阻碍因素和其它团队间出现的问题。经理会制定一个总体计划，以协调开发团队与团队之间的工作。不过，这种方法放弃了团队的自主权，降低了他们在产品上的投入（团队风险共担的意识）。同时它降低了团队的响应能力和灵活性，并限制了团队得到开发过程中出现的学习机会。理查德·哈克曼（Richard Hackman）在他的《领导团队》一书中说，成功的团队会自己意识到并处理好周围环境，包括与其他团队进行协调。哈佛商学院的罗莎贝丝·莫斯·坎特（Rosabeth Moss Kanter）在她的工作场所赋能研究中写道，随着世界变得更具颠覆性，“‘意外’和变更要求的数量不断增加，公司必须越来越多地依赖他们的员工可以就可能没有常规响应的问题做出决定…”（变革大师：美国公司的创新与创业精神）。同时，经验表明，只有团队和个人接受自己决策的责任和问责时，才具有真正的自主权。尽管“从上面”的指示可能会为自主决策创造空间，但只有当“下面”的人打算占领该空间并按照该意图采取行动时，自治才成为现实（组织的社会心理学）。
自治团队不仅对变化更敏感且更具适应性，它们是工作满意度的唯一可持续来源（《一种模式语言：城镇，建筑物，建筑》）。另一方面，没有一致性的自治会导致每个团队朝自己的方向发展，从而损害产品和组织（《全面》）。
因此：将协作的权利和责任赋给团队本身，从而共同实现产品负责人确定的目标。允许团队找出协调工作的最佳方法。
成功的对齐要求每个开发团队中的每个参与人员都必须能看到整个产品，包括其愿景及其目标。通常，这将涉及将产品负责人团队扩展到Scrum团队认为合适的水平。开发团队将使用其部分能力来支持产品负责人。
规模扩展总会根据情况而定，因此，具体的协作形式将由开发团队确定，但是典型的策略包括：
· 同时冲刺—使用组织冲刺脉冲（Organizational Sprint Pulse），以相同的节奏和时间，同时迭代冲刺。
· 维护一份共同的完成定义（Definition of Done）
· 共同的Sprint计划，Sprint评审和其他必须的Scrum活动
· 举行共同的梳理产品待办列表（Product Backlog）活动
· 创建半正式的不断优化的志趣相投者的网络，利用团队之间的共同能力，如架构，以主动处理事先已知的问题
· 在团队的每日Scrum活动之后，建立一个常规的Scrum of Scrums会议，可以是每天，用以解决紧急的依赖关系和问题，并使之完成（请点击参阅“完成定义”）。
不管协调依赖关系和讨论障碍的正式流程是什么，团队都不应把解决问题的时间推迟到Scrum of Scrums。团队在出现障碍时就要对其进行处理。 当团队需要协调时，团队可以彼此交谈，而非一直等待到计划中的下一次会议。开发团队应该自我组织以完成工作，并使用依赖优先的原则进行最大程度地降低依赖风险。ScrumMaster可以帮助消除开发团队进展中的障碍，并且团队可以触发紧急程序作为最后的手段。团队及其成员之间自发互动和临场发挥的协作的水平才是衡量Scrum of Scrums有效性的真正标准。
团队及其成员在将问题带入Scrum of Scrums时，应该是出于对产品的自豪感，而非出于恐惧，甚至不是出于责任。
Scrum of Scrums是一种完善的模式，最早于1996年在IDX Systems（现为GE Healthcare）上实施。Jeff Sutherland当时是工程部高级副总裁，肯·施瓦伯（Ken Schwaber）担任顾问以帮助推广Scrum。该项目涉及到八个业务部门，而每个部门都有多个产品线。每个产品都有自己的Scrum of Scrums。一些产品有多个Scrum of Scrums和更高级别的Scrum of Scrums。每个产品都必须以三个月或更短的发布周期投放市场。所有产品每六个月必须进行一次完全集成，升级和部署，以支持像斯坦福医疗系统等区域性医疗保健供应商。从此示例可以明显看出，可以存在多个甚至是并行的Scrum of Scrums，而每日Scrum of Scrums（当做会议）都可以分为具有独立焦点的子会议。最早提到Scrum of Scrums的出版物是在2001年（Cutter IT Journal：伟大的方法论辩论），它也出现在2011年的Scrum论文中。
译者：Leo Yan
校对：Emma叶超
参考资料：
（1）A Scrum Book：34 Scrum of Scrums
