敏捷之旅--携程Scrum Master 新官上任三把火？

 

随着敏捷在国内的推行，越来越多的公司和组织开始使用敏捷领导团队。 敏捷团队如雨后春笋之势涌现。 敏捷教练的团队也越来越壮大。

 

原先只需要一个敏捷教练就能搞定，但是随着团队越来越多，我们难免会将一些新成立的或者已有的团队交接给新的敏捷教练。 如何做好敏捷团队的交接也是我们面临的最现实的一个挑战。

 

每次当有新的scrum master入职，接到领导分配给他的一个scrum Team，会思考的第一个问题，可能就是：我到底要做些什么。

 

情境领导模型

 

对于如何领导一个敏捷团队，Mike Cohn的一篇文章对此进行了详尽的阐述。 （引1）

 

Paul Hersey的情境领导模型，该模型描述了团队的四个准备阶段，处于每个阶段中团队的意愿和团队能力都有所差异。

 

根据Hersey的说法，领导者需要调整自己的行为以适应团队的准备程度。并因此引入了任务行为与关系行为：

 

以上模型清晰的阐述了一个scrum master需要基于团队的状态，调整带领团队的方式。看完上面的模型，你可能非常认同这个关系和任务行为模型。 当你开始认真琢磨如何使用这个模型的时候，你可能会突然发现无从下手。 对于一个刚刚接手一个scrum的scrum master来说，直接根据以上模型应用到自己的团队，几乎是不可能的事情。在我们试图按部就班的按照模型采取行动的时候，我们可能会处处碰壁。

 

我们一直在强调，研发人员，产品经理并非资源。 他们并非机器。 我们在与其接触时，不能用熟悉一个机器的方式去对待。 比如，家里新购置了一个洗衣机， 我可能打开包装的第一时间，就是研究它的使用手册，因为这个机器的功能是已经固化的，我们学习使用手册，就能够对它进行全面的了解。 而这一时间大概可能就是半个小时。 而现在，我们将面对的是一个由“人”聚合的组织。 如果你之前做过项目经理， 在PMP中一定也学习过，变数最多的、最难以了解/控制的事物及是“人”。 因此，我希望能够在铺天盖地的学习与宣讲scrum基本知识的同时，再强调“人”与“人”的关系。

 

融入团队

 

对于Hersey的模型，我觉得更适合已经带领团队有一段时间的scrum master。 而在应用这个模型与刚接手一个新团队之间，还存在着一个很大的gap。 我个人暂时把它叫做 “融入”(familiarize)。

 

俗话说： “知己知彼， 百战百胜“ 。 在不了解团队成员的时候， 贸然采取任何行动都是鲁莽的。 在刚接手一个新的团队时，我们充满信心准备改变这个团队时，可能会遇到以下一些情况：

 

• 抵触：和之前的认知产生冲突，无法认同与适应，直接表现为不合作
• 烦躁： 不理解为什么要改变，整天被打扰被要求适应新的流程。但自己也不知道是否正确，因此处于变与不变纠结的边缘
• 欺骗： 自我防御的一种。不表态，也不愿意告诉别人真实的想法，怕因此收到别人对他能力的质疑。
• 阳奉阴违： 表面上赞同，但内心不认可。 不理解新的规则， 不认为新的规则可以解决现在的问题。

 

如果一个敏捷教练一开始就收到了第一种或第二种情绪，你可能会知道自己或许推进的有问题，或许能够做及时的调整。 但是如果收到的是第三种或第四种情绪， 那么你可能会花费更多的时间去识别，甚至会激发团队产生第二种和第一种情绪，并有可能在无法获取团队信任的路上越走越远。

 

有一次我在推行一个新的工具的时候，我自认为和团队的成员比较熟， 因此直接和团队说我们第二天就开始用新工具。 接下来第一周大家觉得很新奇，看起来都愿意使用 （阳奉阴违）。 第二周开始有个别同事反馈不好用，我去做了一个普遍的调研，也只有零零星星几个人觉得有些问题，其他大部分都还是觉得挺好 （欺骗）。 第三周，我开始从团队外的同事获取到一些信息，得知大部分人都觉得这个新工具很浪费时间 （烦躁）， 可以在团队调研的时候，仍然没有获取真实的想法。 第四周刚开始的时候， 就收到的上级领导的投诉 （抵触）。

 

那么我们到底应该怎样““融入”一个团队？

 

答案是： Do nothing （什么也不要做）。

 

不要去尝试立刻改变团队。 不要一上来就宣讲敏捷价值观。 不要一遇到问题就做问卷调研。

 

但是，什么也不要做并不意味着真正的啥都不做。 在“融入”一个团队的时候，最温柔且有效的方式是：

 

观察

 

我们从来都不能否认观察的重要性。在进入一个新团队的时候，很多“说”出来的事情都具有一定的欺骗性。 团队的每一个人的状态，真实的想法，可能都经过一定的“加密”。 细心的观察可以帮助我们发现蛛丝马迹，帮助我们判断真实的状态与想法。 可以观察某个人，也可以观察人与人的互动。尤其在团队成员产生分歧的时候，最容易暴露真实的个性。

 

聆听

在观察的同时，聆听也是获取信息的一条重要途径。 这里的聆听不能算是聊天， 我们不需要加入某个讨论或者某个话题， “碰巧”路过所听到的可能会更加真实。 可以去团队里或附近多走走，听一听他们在说些什么。

 

聊天

基于一段时间的观察与聆听，我们对团队成员有了一些基础的认识。 这时可以找一些机会加入一些讨论与互动。 可以和团队随口聊几句，并保持以聆听为住。 刚开始最好聊一些轻松的话题，而不是聊团队的“问题”。 让团队成员觉得你是一个容易相处的人。

 

赞扬

通过一段时间的观察，聆听，聊天以后，可以在聊天时增加“赞扬”元素。 人们喜欢不是“赞扬”， 而且真实的“赞扬”。 在不了解团队成员的时候，一上来就赞扬，会让团队认为你很“虚”，你的赞扬并不能得到被赞扬人的认可。 在和团队成员有了一定了解的时候，对他“好的行为”做真正的赞扬，这时才可能获得他的认可与信任。

 

那么我们到底应该花多久去“融入”一个团队呢？

 

首先看一下团队大小

 

我们的直觉告诉我们，如果一个很大的团队，人很多，可能要花很长的时间。 这个直觉是对的。 如果一个团队规模较大时，团队内的沟通渠道也会非常大。 假设团队人数是n， 那么团队的沟通渠道的数量 = n(n-1)/2。 如果团队有7个人，沟通渠道就有21条；如果团队有15个人，沟通渠道就有105条。 当一个团队比较大时，我们需要去了解的人（团队人数）和人与人之间的关系（沟通渠道）就会变的非常庞大，所花的时间也会随之增多。（引2）

 

其次看一下团队构成

 

如果一个团队的成员是非单一组成，比如，这个团队成员是来自不同部门，或者不同组别。 那么这个团队的构成就比单一组成的团队要复杂的多。 在融入团队内成员的基础上，还需要做干系人分析， 与团队成员的上级或者更上级做好铺垫与沟通。

 

一般一个10人以内的单一团队，差不多需要1~2周去融入。 如果团队人数更多，或团队更复杂，可能需要更多的精力与时间去融入。

 

团队A

刚接手团队A的时候， 我发现这个团队的目前似乎是在走Scrum的敏捷模式。 交接给我的另一名scrum master告诉我站会不用天天开。 这也引起了我的注意。 我先按照现在模式运行了一周发现，在开站会的时候，产品经理和研发团队都非常不积极，每次都是需要我去push。 因为团队很小，大概研发3个，产品经理2个。理论上站会是一件相对轻松的事情。 但是我也并没有多说，保持现状到第二周。 

 

在开需求梳理会的时候，产品经理告诉我，我们这次没有大需求，只需要对上一个需求做一些小的优化即可。 需求说明会自然也非常短，以及接下来的计划会也非常轻松。到第二次说明会之前，在和产品经理沟通需要把backlog准备好时，他似乎面露难色， 勉强答应我了。 但是过了两天快开需求梳理会时，我发现product backlog里仍然几乎没有需求。 我试探性的和团队成员聊了一下，他们其实并不知情， 如果有需求他们就做，但是没有需求的话也会很为难，他们是由各个职能组因这条产品线而组成的一个团队，如果这次没有需求做，可能就会回归至原团队，但是如果下次又有需求，他们可能需要放下原团队的工作又切换到这条产品线的需求。

 

我去了解了一下这位产品经理的组织构成，他似乎还有其他的工作任务，产品经理只是他的工作构成的一小部分。我心里大概知道是什么情况。 于是，我决定主动去找了产品经理， 告诉他团队成员的反映。 产品经理很艰难的说，我们现在的功能做的差不多了，已经可以满足现阶段的用户需求，他觉得没有必要再产出新的需求了，这样他也可以回归本职。

 

那么现在，这个scrum团队情况已经比较明显。 我不需要质疑产品经理，不需要去协调研发来回切换工作内容，需要的是解散这个团队。 于是我找到产品经理和研发团队的manager聊了一下现状，大家达成一致后，就将团队解散，让团队成员去做真正有价值的事情。

 

团队B

在接手这个团队的时候，看起来一切都很顺利。 团队人数不多，团队里的人也都很容易相处。 但是在第二周，第三周的时候，我们遇到了一个问题。 产品经理反馈需求上线太慢， 上线后问题很多。 产品经理希望能够加快修复问题， 加快AB实验流量放大的速度。 虽然每天我们都在梳理这些问题，研发团队解决问题的速度很快，但是总是有新的问题涌现。 产品经理的心情越来越焦躁，因为离之前承诺老板的上线时间越来越近。 而研发团队也很郁闷，大量涌现的问题不仅需要快速解决，而且还经常遇到一些“奇葩”问题非常棘手。 于是我去找研发团队随意聊了几句，很快就发现了问题本质。 现在这个团队负责的功能的用户流量非常大，稍有不慎就容易产生各种各样的问题，而且研发人员很担心性能问题，如果产品经理一定要在规定时间内上线，有可能性能扛不住系统就会崩盘。 但是研发团队因为和产品经理合作一直不错，遇到问题也是希望能够自己解决并且尽量能够满足产品经理的要求。

 

那么现在，只需将产品经理和研发同学拉在一起，说明两边的困难，并由他们自行权衡解决方案即可。 在这个实战例子中，产品经理意识到了性能指标的重要性，同意了研发同学优先上线一个解决性能的方案后，再将流量放大。 而scrum master也在观察和解决问题的过程中意识到，这个团队的特殊性在于他们负责功能需要集成在巨大客户流量的页面，因此“求稳”也成为了研发和产品经理共同的指标与底线。

 

总结

 

在融入团队的时候，往往不能轻举妄动。 罗杰斯的创新扩散模型（引3）同样适用于发现解决团队内的冲突。 即，在融入的同时也是等待，等待scrum master积攒越来越多的信任，等待团队内问题从土里慢慢显现出来，直到快要激发到最大程度时，再去切入解决，这时解决问题的过程才会更加顺滑，解决问题也才会更加彻底。

 

引1：你怼我们团队不行，那为什么换个ScrumMaster就搞定了？

引2：《敏捷革命》杰夫.萨瑟兰， 团队规模

引3：《创新扩散》埃弗雷特·罗杰斯（Everett M. Rogers）

 

---

部分图片及电子书来源于网络，版权归原作者所有，仅供学习勿作它用。如果侵犯到您的权益，请联系我们。

---

 

推荐阅读

 

• 我在现场 | 2019.05 携程敏捷沙龙
• 别和我谈考核
• 我们的目标是称霸全国
• Apple Watch实现个人Scrum

---