SM到底能服务几个团队

这是每个初步转型敏捷的公司都会问的问题。在回答这个问题之前，我想提醒一下，“有效果才是最好的”这个至理名言，在这个问题，也是适用的。

没明白？没关系，坐下来，我们慢慢说。

这个问题的存在，与SM 本身工作方式有关。去翻翻相关书籍，对于SM的输出都是言之不详。这与SM 本身的工作内容有关。按照SM是教练、团队保护者、引导者来看，SM 是很难有一个可以被认可的工作成果。在这种情况下，若是高层对于敏捷理解不到位，对SM 理解不到位，自然就会产生“SM 到底是干什么的？”好一点的团队明确知道SM 是团队促进者，但是也一定程度与原始PM 概念有重叠；差一点的直接把SM 作为团队服务员，尽做一些打杂的事儿。

在这种情况下，SM 就成了一个极度边缘的角色，甚至会让其他岗位的人兼任，比如PO、比如研发人员。如果团队此时拥有专职SM，自然会被问到“一个SM 能带几个团队呢？”。对，就是这么顺理成章。

回答这个问题之前，我还认真地画了一张模型图给大家演示SM需要的精力与团队敏捷度的关联，这张图可以与“情境领导”结合起来看，效果更佳。

在这个模型中，我们将团队敏捷度作为横坐标，越往右边团队敏捷度越高；而SM 所需要投入的精力作为纵坐标，越往上所需要的精力越高。

这里有人肯定会问什么是团队敏捷度。这里我给出的定义是：团队对于敏捷的理解程度，以及在日常工作中按照敏捷的方式做事的能力。这里的团队包括了研发人员、SM与PO三种角色，并非单单指研发团队，这点需要严格注意。当前不少人对敏捷或者Scrum 的重点全部放到了研发团队和SM身上，而将PO 置之一旁。这绝对是有问题的。PO 作为需求的输入端，如果这端做不好，敏捷是无从谈起的。这是后话，有机会后面说。

而SM 投入的精力就比较好理解，即SM 需要投注的关注度以及引导团队、培训团队所需要消耗的时间。

图中的黑色实现部分为精力与团队敏捷度的关系图，从这个图中能看到，随着团队敏捷度的提升，SM 所需要消耗的精力是逐渐上升的；而到了一个点之后，精力会快速下降。值得注意的是，图中有两条红色虚线和两条绿色虚线。这四条线将这个曲线的四个重要时间点做了标注，也是这张图的核心。

下面分别解释一下这几条曲线的含义：

结合上述几条线的含义，我们就可以对这张模型图进行一个完整的解读了。

很多人可能会疑惑，为什么一开始消耗的精力是比较少的，对于一个敏捷成熟度不高的团队，SM 不会非常头疼么？

上面这个观点单独看来是对的，但是如果你放到敏捷转型的过程中，就会发现不是那么回事。

在转型初期，如图所示，团队敏捷成熟度是不够的，对SM 的认知也较大可能的停留在“监工”的层面，此时SM 的首要任务是获得团队信任。此时不适合、也不可以直接将各种敏捷流程全部推一遍，而是应该以理念灌输、观察以及少量的敏捷实践导入为主，辅以传统意义项目经理的职责，确保工作交付。此时并非SM 不想投入过多的精力，而是此时团队不能理解，SM 贸然投入精力，会适得其反。此时SM 与团队的关系依然区分“你”和“我”，处于E1的状态。

随着团队敏捷成熟度上升，以及对SM 的信任度的提升，SM 可以开始导入更多的敏捷实践，并且可以更加放开手脚的对团队进行引导和教育，而不用担心团队的不满或者反弹。此时SM 与团队的关系开始融洽。

而随着团队与SM关系升温的过程中，最终会达到顶点。这里的顶点并非单纯的SM与团队的默契度，也包含了SM 对团队的判断，即要根据不同团队选择适合当前团队的成熟度即可。但选择的原则是一致的：让团队可以在指导下或者SM 作为服务型领导的前提下，可以完成完整的敏捷研发流程，或者可以粗暴的认为是Scrum或者Kanban。此时处于M1点。

随着团队的敏捷成熟度提升，SM 开始往幕后退，将确保流程的工作逐步移交给团队，即让团队变成流程守护者。这个过程中，SM 的精力主要会集中在如何教导团队去守护流程、促进合作，而不是亲自维护流程。在这个职责移交过程中，SM 的精力消耗会维持在一个相对稳定的水平，但是工作内容会逐渐变化。除了保护团队、解决障碍这部分工作依然存在且无法移交外，其余的工作内容将会从100%流程保证+0%的团队教练，逐步变成50%流程保证+50%团队教练，直到最后的0%流程保证+100%团队教练。至此，SM 彻底变形为团队保护者+团队教练的混合职责，而原先流程保证的工作，完全移交团队。此时处于M2点。

最后随着SM 的工作内容转变完成，SM 工作量将会快速下降。此时下降的原因在于两点：1. 流程已经非常流畅，SM 不需要时时刻刻都盯着流程和团队 2. 能完成M2 的转变，代表着SM 与团队已经经历过非常多的事情，团队已经过了能快速改进的阶段，且团队内部的默契已经达成，甚至团队一定程度上可以解决过去需要SM 才能解决的问题。此时SM 过分干预已经不是那么必要，SM 此时更像是吉祥物+咨询师的存在，给与团队力量以及在团队有问题的时候挺身而出。

有一点是毋庸置疑的，当团队经过了这段时间的打磨，对SM的依赖必然会比团队最初的时候还要低，单纯从团队的磨合度就应该能得出这个结论，更何况在前面的几个时间点，我们还对团队进行了培训与引导，而这些培训与引导也包含了大量的团队关系、配合等内容。此时位于E2点。

既然SM 精力需要会如此降低，那是否可以降到极限？即将SM 精力降为0，本质上取消该组的SM。

这里的回答是：可以，但是有SM，团队会更加容易变得更好。

对此有疑问的各位，可以回头看一下SM的职责是什么？团队教练与障碍清除者。虽然在E2 点，团队的确是可以取代一部分的SM 职责，但是依然有部分工作是团队无法解决的，这部分工作主要集中在需要外部资源进入团队临时协助的时候。这点团队也能做，但是效率极低。

另外，反问一下，有了SM 会让团队更糟糕还是更好？回答一定是更好对不对？既然如此，一个消耗不了太多精力，又能给团队提供咨询，且能让团队变得更好的SM，你撤销的目的是什么呢？

OK，感谢您看到这里，看我絮絮叨叨说了那么多。其实上面的所有内容都没有直接回答本文开头的问题。原本上面的内容就不是为了回答这个问题的，因为那个问题在我看来其实很简单，但根据我一贯的习惯，我更喜欢将思考过程说出来，帮助大家去理解，并在自己的团队中进行自己的判断，毕竟敏捷本身就是一个“实践学科”，所以给答案不如给思考过程，你说是么？

毕竟如果SM 都不能起到效果，有没有SM 也不是很关键。而如果因为对SM 精力消耗曲线不理解而影响到SM 的效果，那岂不是很可惜？

你上面说了那么多，到底能带几个？

好吧好吧，我说我说。但是我依然要强调，这个数字每个团队都不一样，我只能给出我的个人判断。

一般来说，我不认为一个SM 可以带超过3个以上的团队，我个人比较喜欢一个SM带不超过2个团队，对于重点项目我喜欢一对一。

其实简单想一下，你就会发现，如果一个SM带3个团队，则光是站会的延续时间就要45分钟，最早的团队与最后一个开早会的团队的时间相差了30分钟，这30分钟是极有可能被浪费的，尤其是在团队的敏捷成熟度不足的情况下。

如果再思考一下其他几场会，你会发现SM 空余的时间已经不多，这其中再穿插培训、引导、教练、排除障碍等工作，SM 的工作强度会直线上升。这不论是对SM 还是团队，都是一种伤害。

所以，如果人手不是那么紧，这个数字可以在1-1.5之间摇摆，如果真的人手很紧，请选择2。如果一定要选择3，那么就做好招人的准备，否则随着团队敏捷成熟度提升，SM 工作量会崩。

当然也会有人说，那如果所有的团队成熟度都到了E2点，那么SM 岂不是就没事儿干了？工作量怎么办？这个问题说实话，我无法回答，因为这与公司的企业文化密切相关，也和公司如何看待员工的方式有关。因此我能回答的就是：如果可以，请培养一个新人SM，并代替原来SM ，将原来的SM 资源释放去其他初始团队。如果不想再增加新人的Head Count，那么也可以将SM 的职责指定给某个研发人员，然后把SM 资源释放去其他团队。

什么，你跟我说没有其他新的团队？那我还是建议不要再考虑SM的事情，而是去考虑一下公司业务与产品的事情比较好。毕竟团队交付能力再提升，却没有相应的有业务的人员配置，这还是比较可怕的。

除了“能带几个团队？”这个小节外，都是我个人对于SM 工作量的思考，如果您对此有什么不同意见，请留言告诉我。