SoS，不是呼救，是一种大规模敏捷团队的组织方式

随着组织中的scrum团队增加，特别是在多个scrum团队比较紧密地工作在一个产品上的时候（对大型的公司这个非常正常），我们就不得不面对不同团队之间的协同的挑战，所以寻找和探索大规模敏捷的解决方案就变得很自然。行业里目前有一些大规模敏捷的解决方案，最基础的就是Scrum of Scrums（SoS），复杂一点的模型有Scaled Agile Framework（SAFe），Large Scale Scrum（LeSS）， Disciplined Agile Delivery（DAD）。我会对每个模型都专门一个篇幅做介绍，这篇短文先只介绍Scrum of Scrums。

当多个scrum team工作在同一个产品上的时候，虽然我们努力想做到全功能的特性团队，希望能在一个团队里做完所有的事情，而不需要依赖其他的团队，但这明显只是一个非常理想的状态；团队之间不可避免会有依赖，需要协同。Scrum of scrums的做法就是每个scrum团队选出1-2个代表，团队的代表聚在一起分享进度和协同解决依赖。如果组织很大，scrum团队太多，也会出现先按部门的划分在不同的部门里做SoS，然后不同部门的代表再聚在一起做“Scrum of Scrum of Scrums”。也就是分层次的SoS。

SoS非常简单，它的主要形式就是一个（或一系列）会议。

最频繁的情况是每天一次，最少的情况下是每周一次。 我个人不太赞成每天一次的SoS，原因是一般来说团队之前还没有每天都同步的需要，如果真的有说明工作联系太过紧密了，可能背后是团队划分或是任务划分出了问题，我们需要先解决组织或任务划分问题。一周一次的会议相对于2周一个迭代的情况又太晚，所以一周2-3次的SoS相对比较合适。

一般很自然的会让scrum master去参加SoS会议，但这不是一定的，我希望能看到不同的团队有不同的做法。如果团队明显对其他团队有技术相关的依赖的时候，团队里地技术专家更需要参加SoS以从技术的角度阐述自己团队的需求。 总之，团队自己决定谁去参加SoS最合适，甚至轮流去参加也是一个可行的办法。

这个会议和scrum team里的每日站立会议非常像，我们也是基于回答几个问题来操作。 但是考虑到会议的目的不同，SoS需要每个团队代表回答的问题也有一些区别，一般情况我们会让大家回答下面这几个问题：

我们一定要注意，SoS会议千万别搞成了scrum master来轮流汇报工作的会议，这不是SoS的目的，这个会议要解决的事团队之间相互影响和依赖的问题，所以我们希望能暴露出此类问题，并尝试在下次会议之前解决它。 是的，如果会议中暴露的问题不能在下次会议前解决的话，我们就总是在会议上听到相同的问题，最终这个会议也会失去吸引力，变得没有意义。

上面这些当然都非常重要，如果会议上发现相关的问题需要会后通知合适的人去解决，但这些都不是SoS的目的，我们要保证SoS会议的关注点，不要偏题。

这个会议就像团队的daily meeting类似：在议程上其实不需要人来主持，我们通过每个参与团队回答固定的几个问题来进行，但我们仍然需要一个“Scrum of Scrums Master”来：

这个人一般希望是由产品负责人来担任，有多个产品负责人的话也可以轮流来担任。

我见过另一种更简单的SoS方式：每个团队都有一个PO或PO和团队非常紧密的工作在一起，PO对团队的进度、问题都非常清晰，而且所有的PO又处在一个单独的PO实体团队中，那么所有的PO会定期的有自己的团队会议，PO在这个会议上会做SoS。

关于协同不同scrum team的工作，除了SoS，还有一个简单必要的做法就是确定统一的“完成的定义”（Done of Definition），不同的团队基于相同的DoD工作可以极大的改进不同scrum team之间协同的困难，关于DoD以后单独来讲。