Scrum Master与项目经理的区别

常踩的坑：很多企业没有彻底地应用Scrum，而是对Scrum框架里的元素有所选择地应用。比如，组织里原来有项目经理或项目Leader的角色，在引入Scrum的时候，组织简单地把项目经理（PM: Project Manager）或团队组长(TL: Team Leader)对应到了Scrum Master上。

一人兼了两个角色，而这两个角色是定义在不同的流程和价值观里，相当于一个人同时上了两条船，而两条船以不同的方向和速度航行。所以，必然一条船要妥协牺牲。因为引入新事物更加困难，因此往往最后妥协的是Scrum。于是，当一个人身上的新旧两个角色博弈的时候，失败的总是新角色。如果项目经理或团队组长保持原有的项目管理方式和思想兼任Scrum Master，经常最终只是应用了Scrum的流程却没有领会Scrum的精髓，逐渐发展成像第一章介绍的船货膜拜式敏捷。

Scrum Master和传统项目管理方式里的项目经理、团队组长在角色定义上有本质区别：

首先，Scrum框架里没有项目经理、团队组长这样的角色。传统项目经理的职责被Scrum Master、产品负责人、开发团队所分担。比如，产品定义的职责由产品负责人来承担；项目计划的职责由产品负责人和开发团队共同承担；项目执行和监控的职责由开发团队承担；团队管理的职责，通过Scrum Master引导团队自管理完成。

Kenneth S.Rubin对Scrum里各角色所承担的项目管理活动做了具体映射（下表）：

 

传统项目管理活动在Scrum里的映射

资料来源：《Scrum精髓-敏捷转型指南》（Essential Scrum: A Practical Guide to the Most Popular Agile Process），2014年5月

其次，在管理方式上，传统的项目经理是命令下达式，与团队的每个人点对点地沟通和协作，因此整个团队是以项目经理为中心在运转，大家之间的信息不对称、不透明，项目经理掌握着信息的全集，而团队的每个成员基本只掌握自己的任务以及与自己任务相关的信息

而在Scrum里，Scrum Master除了维护Scrum流程外没有其他权利，他对团队也没有发号施令的权利。Scrum Master通过引导的方式，促进团队彼此沟通和协作，而不是以某个人为中心。当Scrum Master发现团队成员之间、或者团队与外界出现了协作障碍，他引导大家去除协作障碍，从而确保协作的紧密性。因此，团队成员之间通过自组织实现协作，信息的交换是对称和透明的，不需要以某个人为枢纽（如下图）。

 项目经理 vs. Scrum Master

很多企业变革的决心很大，干脆将项目经理、团队组长等Title(职位名称)去掉，指导这些同事转型为Scrum Master。然而角色的转型不是上一堂课就可以实现的，需要长期的刻意练习。从项目经理转型为Scrum Master的常见现象是：戴着Scrum Master的Title(职位名称)，但是管理风格没有改变，于是给团队的印象就是换了个Title的名字而已。比如：

1. 站会上，经常见到每个人给Scrum Master汇报进展，然后Scrum Master给每个人指示：他今天该做什么。每个人汇报完毕后，会议结束。
2. 当团队的Sprint目标没有达到的时候，Scrum Master自己分析原因，然后做决定：“我们这个Sprint的目标没有达到，我认为原因是….，所以，我们应该这样做….具体来说，小李，你负责…；小王，你以后要注意…。”

而合格的Scrum Master通过问问题的方式来引导团队思考，决定由团队自己做：“我们这个Sprint目标没有达到，大家认为是什么原因呢？….那么大家认为咱们需要采取什么措施改进呢？…大家觉得我需要在哪些方面帮助大家，才能达成更好的效果呢？”