随着组织中的scrum团队增加，特别是在多个scrum团队比较紧密地工作在一个产品上的时候（对大型的公司这个非常正常），我们就不得不面对不同团队之间的协同的挑战，所以寻找和探索大规模敏捷的解决方案就变得很自然。行业里目前有一些大规模敏捷的解决方案，最基础的就是Scrum of Scrums（SoS），复杂一点的模型有Scaled Agile Framework（SAFe），Large Scale Scrum（LeSS）， Disciplined Agile Delivery（DAD）。我会对每个模型都专门一个篇幅做介绍，这篇短文先只介绍Scrum of Scrums。
Scrum of scrums
当多个scrum team工作在同一个产品上的时候，虽然我们努力想做到全功能的特性团队，希望能在一个团队里做完所有的事情，而不需要依赖其他的团队，但这明显只是一个非常理想的状态；团队之间不可避免会有依赖，需要协同。Scrum of scrums的做法就是每个scrum团队选出1-2个代表，团队的代表聚在一起分享进度和协同解决依赖。如果组织很大，scrum团队太多，也会出现先按部门的划分在不同的部门里做SoS，然后不同部门的代表再聚在一起做“Scrum of Scrum of Scrums”。也就是分层次的SoS。
怎么做SoS
SoS非常简单，它的主要形式就是一个（或一系列）会议。
首先，这个会议多久开一次？
最频繁的情况是每天一次，最少的情况下是每周一次。
我个人不太赞成每天一次的SoS，原因是一般来说团队之前还没有每天都同步的需要，如果真的有说明工作联系太过紧密了，可能背后是团队划分或是任务划分出了问题，我们需要先解决组织或任务划分问题。一周一次的会议相对于2周一个迭代的情况又太晚，所以一周2-3次的SoS相对比较合适。
谁可以作为团队的代表参加SoS
一般很自然的会让scrum master去参加SoS会议，但这不是一定的，我希望能看到不同的团队有不同的做法。如果团队明显对其他团队有技术相关的依赖的时候，团队里地技术专家更需要参加SoS以从技术的角度阐述自己团队的需求。
总之，团队自己决定谁去参加SoS最合适，甚至轮流去参加也是一个可行的办法。
会议讨论什么内容？
这个会议和scrum team里的每日站立会议非常像，我们也是基于回答几个问题来操作。
但是考虑到会议的目的不同，SoS需要每个团队代表回答的问题也有一些区别，一般情况我们会让大家回答下面这几个问题：
- 从上次会议到现在你们team做了哪些任务？
- 到下次会议之前你们team计划完成哪些任务？
- 你们team有哪些困难需要其他team协助的？
- 你们有没做什么会影响其他team工作的决定的？
我们一定要注意，SoS会议千万别搞成了scrum master来轮流汇报工作的会议，这不是SoS的目的，这个会议要解决的事团队之间相互影响和依赖的问题，所以我们希望能暴露出此类问题，并尝试在下次会议之前解决它。
是的，如果会议中暴露的问题不能在下次会议前解决的话，我们就总是在会议上听到相同的问题，最终这个会议也会失去吸引力，变得没有意义。
SoS上不讨论什么？
- 不增加新的backlog item
- 不做backlog item分解
- 不做项目计划和管理
上面这些当然都非常重要，如果会议上发现相关的问题需要会后通知合适的人去解决，但这些都不是SoS的目的，我们要保证SoS会议的关注点，不要偏题。
SoS需要主持者吗？
这个会议就像团队的daily meeting类似：在议程上其实不需要人来主持，我们通过每个参与团队回答固定的几个问题来进行，但我们仍然需要一个“Scrum of Scrums Master”来：
- 在必要的时候维持会议约定（按时参加，关注于既定议程）
- 记录会议上暴露出的问题
- 推动问题在会后能背解决
这个人一般希望是由产品负责人来担任，有多个产品负责人的话也可以轮流来担任。
其他
另一种简化的SoS
我见过另一种更简单的SoS方式：每个团队都有一个PO或PO和团队非常紧密的工作在一起，PO对团队的进度、问题都非常清晰，而且所有的PO又处在一个单独的PO实体团队中，那么所有的PO会定期的有自己的团队会议，PO在这个会议上会做SoS。
DoD
关于协同不同scrum team的工作，除了SoS，还有一个简单必要的做法就是确定统一的“完成的定义”（Done of Definition），不同的团队基于相同的DoD工作可以极大的改进不同scrum team之间协同的困难，关于DoD以后单独来讲。
