第六章 如何带领Scrum团队
6.2正确理解关键角色：Scrum Master
1、Scrum Master与项目经理的区别
常踩的坑：
很多企业没有彻底应用Scrum，而是对Scrum 框架里的元素有选择地应用。比如，在引入Scrum的时候，组织简单地把Scrum Master 的职责移到了项目经理或团队组长的身上，即一人身兼两个角色。
这两个角色是定义在不同的流程和价值观里的，相当于一个人同时上了两条船，而这两条船在向不同的方向以不同的速度航行。所以，有一条船必然要妥协、牺牲。当一个人身上的新旧两个角色博弈的时候，失败的总是 新角色。如果Scrum Master由项目经理或团队组长兼任，但其却依旧保持原有的项目管理方式和思想，那么最终组织也只是应用了Scrum的流程却没有领会Scrum的精髓，从而逐渐发展成“船货膜拜”式敏捷。
Scrum Master 和传统项目管理方式里的项目经理、团队组长有角色定义上有本质区别。
首先，Scrum框架里没有项目经理、团队组长这样的角色。传统项目经理的职责被Scrum Master、产品负责人、开发团队所分担。比如，产品定义的职责由产品负责人来承担； 项目计划的职责由产品负责人和开发团队共同承担； 项目执行和监控的职责由开发团队承担； 团队管理的职责，通过Scrum Master引导团队自管理完成。
肯尼斯 S鲁宾对Scrum里各角色所承担的项目活动做了具体映射。
其次，在管理方式上，传统的项目经理是 命令下达式，与团队的每个人点对点地沟通和协作，因此整个团队是以项目经理为心心在运转，大家之间的信息不对称、不透明，项目经理掌握着信息的全集，而团队的每个成员基本上只掌握自己的任务以及与自己任务相关的信息。
而在Scrum里，Scrum Master除了维护Scrum流程外没有其他权力，他对团队也没有发号施令的权力。Scrum Master通过 引导方式，促进团队彼此沟通和协作，而不是以某个人为中心。当Scrum Master发现团队成员之间，或者团队与外界出现了协作障碍时，他会引导大家去除协作障碍，从而确保协作的紧密性。因此，团队成员之间通过自组织实现协作，信息的交换是对称和透明的，不需要以某个为枢纽。
很多企业变革的决心很大，干脆将项目经理、团队组长等职位名称去掉，指导这些人转型为Scrum Master。然而角色的转型不是上一堂课就可以实现的，需要长期的刻意练习。从项目经理转型到Scrum Master的常见现象就是，项目经理戴着Scrum Master的“帽子”，但其管理风格并没有改变，所以给团队的印象就是换了个头像而已，常常出现以下情形：
1）站会上，经常见每个人给Scrum Master汇报进展，然后Scrum Master给每个人指示-----今天你该做什么。每个人汇报完毕后，会议结束。
2）当团队的Sprint目标没有达到的时候，Scrum Master自己分析原因，然后做出决定：“我们这个Sprint的目标没有达到，大家认为是什么原因呢？那么大家认为咱们需要采取什么措施改进呢？大家觉得我需要在哪些方面帮助大家，才能达到更好的效果呢？”
2、Scrum Master的职责
很多人对Scrum Master职责的认识很片面，以为就是支持Scrum框架里的计划会议、每日站会、回顾会议和评审会议。因此，这里有必要说说Scrum Master到底有哪些职责。
1）过程权威
Scrum Master负责维护Scrum团队的流程，确保团队遵守工作协议，指导团队践行敏捷的价值观、原则，以及实践Scrum。因此，Scrum Master 是流程负责人。
常踩的坑：
公司L引入了Scrum以后，试点团队在Sprint执行过程中，职能经理们很好奇团队的试点进展，于是主动要求参加Scrum团队的敏捷活动。在Sprint计划会议上，经理层给团队指示这个Sprint该做什么，要达到什么目标； 在回顾会议上，当团队讨论有哪些地方需要改进时，经理层加入讨论，就团队的改进事项下达指示。
这时候Scrum Master怎么办？大部分Scrum Master都选择了顺从，因为职能经理是他们的上司或上司平级。选择顺从，就意味着流程负责人的权威性被剥夺。
更好的做法是，Scrum Master与经理层提交沟通，当然，如果自己不方便沟通，可以委托教他教练或者同事与经理层沟通。并且，职能经理层在参加Scrum各种活动过程中，需要保持沉默，以锻炼团队的自管理能力。如果经理层对团队的日常动作横加指示，不但没有帮到团队，反而干预了团队的正常运转，剥夺了团队的自管理的权力。而如果经理层长期这样做，团队势必会退回到从前，即上级说什么，我们就做什么，反正我们计划、讨论了也没有用，无论 对错，都是领导对结果负责。
此外，Scrum Master需要让经理：你自己拥有掌控流程的权力。如果经理层一味干涉，会剥夺这一职责，让你的工作无法继续下去。
2）牧羊犬
Scrum Master负责保护团队不受外界干扰，让团队将精力集中在每个Sprint的交付上。工程师的开发工作经常被上面的职能经理、其他利益干系人或在项目周期打配合的团队所打断。所以Scrum Master需要为团队充当一个”真空防御层“，拦截外界干扰，让团队专心工作。
案例：
绵羊型Scrum Master
企业M的一个Scrum团队的产品负责人，经常在Sprint进行中忽然想起有重要的需求在Sprint计划时漏掉了，要求在这个Sprint加上，而Scrum Master并没有异议，团队则全盘接纳。为什么呢？因为这位产品负责人比较资深，职位级别比Scrum Master和开发团队的任何一个人都高。
这样做的后果是什么呢？团队为了满足产品负责人的临时起意经常加班赶工。有了一次特例 后，就有第二次、第三次。产品负责人也不觉得这样做有什么不妥，反而形成了习惯； 而团队对于Sprint的目标不也再尊重，对Scrum 的工作方式也不会喜欢。
3）清道夫
Scrum Master负责清扫妨碍团队生产效率的一切障碍。这里并不是说Scrum Master要亲自撸起袖子来干，而是说Scrum Master引导团队自管理，由团队成员自己清除障碍，但是当团队自己搞不定的时候，Scrum Master将责无旁贷。
案例：
保姆型Scrum Master
小楠，一名由技术领导者转型的Scrum Master一起对团队尽责尽职。团队每个成员遇到困难都找他，他经常坐工程师旁边帮着调试代码攻关。公司技能能力最强的也是他，任何技术攻关都由他亲自带头编码调度，没有他攻不破的困难。站会上，每个人提到了自己遇到了什么困难，他都用小本子记下来，会后找这些同事一一解决。
像小楠这样每天亲力亲为地给大家解决问题，虽然得到了大家的喜爱，但这种保姆型Scrum Master对团队的自我成长反而不利。
4）教练
Scrum Master教练的对象是产品负责人和产品开发团队。Scrum Master负责移除产品负责人和开发团队之间、开发团队成员之间的协作障碍。就像球场的教练，Scrum Master观察团队如何运作Scrum,帮助团队提升敏捷的实践能力，改变团队的思维模式，从而提升团队的整体效能。Scrum Master也会辅助产品负责人开展与开发团队相关的活动，比如梳理Backlog等，并引领团队持续优化产品，实现产品的最优产出。
5）服务型领导
服务型领导（Servant Leadership）是领导力的一种。Scrum Master是典型的服务型领导者。他服务于团队，服务于产品负责人，服务于组织。关于服务型领导，以及什么时候用什么样的领导风格，将本后续介绍。
6）变革代言人
做组织变革的代言人是对Scrum Master最高的要求。很多企业的Scrum Master虽然把自己的团队带领得很好，但是影响范围仅限于自己的团队，对与团队周边的人和组织没有产生推进变革的作用。
但是，这不是Scrum Master自己的问题，也并不意味着Scrum Master要以一己之力承担推进组织变革的责任。组织需要建立敏捷转型委员会等机制，为Scrum Master推进和影响组织变革建立顺畅的通道。
3、Scrum Master兼职怎么办？
常见疑惑：
问：Scrum Master必须是全职的吗？
答：不一定。从现实来看，在国外，全职的Scrum Master很多；而在中国，90%以上的企业是由团队的一个成员兼任了Scrum Master的职责，也许是因为很多中国企业认为单独由一个人来承担这个职责成本有点高。
但是，兼职的Scrum Master会面临很多挑战。对于兼职的Scrum Master来说，需要注意以下三个方面：
1）为行使Scrum Master职责分配充裕的时间
团队刚开始引入Scrum的时候，需要Scrum Master自己投入大量的时间和精力学习和练习Scrum.所以兼职的Scrum Master需要预留跢的时间来学习和练习新方法。
案例：
在一家互联网企业T，小燕是团队的测试工程师。团队开始试点Scrum，领导任命她做Scrum Master。她和领导不知道Scrum Master的工作需要花很多时间，以为只是占用Scrum框架里的几个会议的时间而已。小燕开始了Scrum Master之旅后，发现Scrum Master工作中很多时间 是无形的。
每次开计划会议、评审会议、回顾会议之前她都需要做一些准备工作。她发现，如果不做任何准备工作直接开会，会导致会议效率低下，或者没有达到会议的目标就草草结束。
每日站会之后，她需要对团队的阻碍事项一一做出处理和跟踪。
针对团队暴露出来的问题，她需要思考怎么引导团队解决和改进。因为她的关注点是团队如何高效地实现产品目标，而其他同事的关注点容易局限在”当前Sprint里我认领的任务“。
在实践Scrum的过程中，她碰到了很多困惑和难题，需要自己读书、学习，以便找到解决问题的方法。
此外，部门定期组织Scrum Master的交流和研讨，分享和传播Scrum，这也占用了她一些时间。
所有这些，都是她在做一名全职测试工程师的工作时间之外来做的，导致她自从承担了Scrum Master的职责之后，不停的加班，精神压力也急剧上升。
依据经验，如果是初次做Scrum Master，在前三个月内至少应该投入70%的时间在Scrum Master的工作上。随着团队对Scrum越来越熟练，Scrum Master 对其投入的精力可以减少，但是应该保证投入30%~50%的时间，以确保团队持续改进。
不幸的是，中国大部分企业的做法是，让一个员工兼职了Scrum Master的重要职责，却没有给她/他富裕的时间，而是让她/他自己挤出时间来承担一个新的职责。这是对这个职责本身的不尊重。兼职的Scrum Master不仅做不好新的工作，而且原有的工作也会受影响。
2）角色切换时，明确此刻”我是谁？“
对于兼职的Scrum Master，当他与团队和外界协作的时候，要明确当下自己在行使角色和职责，否则会让团队甚至自己产生困惑。
案例：
在企业T，作为测试工程师的小燕兼职做了Scrum Master。她在主持回顾会议的时候，首先，她引导大家思考团队有哪些地方需要改进，然后她也会以测试工程师的身份从测试的角度提出几点团队的改进项。她发现自己时而作为Scrum Master引导团队，时而作为测试工程师吐槽，这影响了回顾会议的氛围和流畅性； 同时也让自己疑惑，在大家的眼里，我到底是什么角色？
Scrum Master要注意的是，在同一项目活动中，尽量少做角色的切换。非做不可的时候，要给大家澄清，”我现在提出这个问题是以测试工程师的身份，而不是Scrum Master".这样大家也不会困惑，也便于Scrum Master自己快速进入角色。
3）Scrum Master要被正式任命，并在绩效目标里体现其工作职责
案例：
在企业T，小燕的领导只是跟团队说小燕是Scrum Master，但是没有发正式任命的邮件或其他书面通知，周边的团队和组织也不知道。这样给大家也给小燕自己一个印象：Scrum Master的工作只是个临时的活。
此外，小燕的绩效目标仍旧是一个测试工程师的目标和考核项，完全没有Scrum Master的元素。小燕自己很困惑：“怎么才能算是做好了Scrum Master的工作呢？既然绩效里没有体现这个角色的工作，也许领导并不看重."
如果领导层真的重视敏捷转型，就应该对Scrum Master的角色认真起来，正式任命并发布通知，并且使其工作职责在Scrum Master的绩效目标和考核中予以体现。
了解更多内容，请关注微信公众号：
