很多企业没有彻底地应用Scrum,而是对Scrum框架里的元素有选择地应用。比如,在引入Scrum的时候,组织简单地把ScrumMasterr的职责移到了项目经理或团队组长的身上,即一人身兼两个角色。
这两个角色是定义在不同的流程和价值观里的,相当于一个人同时上了两条船,而这两条船在向不同的方向以不同的速度航行。所以,有一条船必然要妥协、牺牲。当一个人身上的新旧两个角色博弈的时候,失败的总是新角色。如果ScrumMaster由项目经理或团队组长兼任,但其却依旧保持原有的项目管理方式和思想,那么最终组织也只是应用了Scrum的流程却没有领会Scrum的精髓,从而逐渐发展成“船货膜拜”式敏捷。
ScrumMaster和传统项目管理方式里的项目经理、团队组长在角色定义上有本质区别。
首先,Scrum框架里没有项目经理、团队组长这样的角色。传统项目经理的职责被ScrumMaster、产品负责人、开发团队所分担。比如,产品定义的职责由产品负责人来承担;项目计划的职责由产品负责人和开发团队共同承担;项目执行和监控的职责由开发团队承担;团队管理的职责,通过ScrumMaster引导团队自管理完成。
肯尼斯·S.鲁宾(KennethS.Rubin)对Scrum里各角色所承担的项目管理活动做了具体映射(见表6-1)。
表6-1传统项目管理活动在Scrum里的映射
资料来源:《Scrum精髓:敏捷转型指南》(EssentialScrum:APracticalGuidetotheMostPopularAgileProcess),2014年5月
其次,在管理方式上,传统的项目经理是命令下达式,与团队的每个人点对点地沟通和协作,因此整个团队是以项目经理为中心在运转,大家之间的信息不对称、不透明,项目经理掌握着信息的全集,而团队的每个成员基本上只掌握自己的任务以及与自己任务相关的信息。
而在Scrum里,ScrumMaster除了维护Scrum流程外没有其他权力,他对团队也没有发号施令的权力。
ScrumMaster通过引导的方式,促进团队彼此沟通和协作,而不是以某个人为中心。当ScrumMaster发现团队成员之间,或者团队与外界出现了协作障碍时,他会引导大家去除协作障碍,从而确保协作的紧密性。因此,团队成员之间通过自组织实现协作,信息的交换是对称和透明的,不需要以某个人为枢纽(如图6-3所示)。
图6-3项目经理与ScrumMaster的对比
很多企业变革的决心很大,干脆将项目经理、团队组长等职位名称去掉,指导这些人转型为ScrumMaster。然而角色的转型不是上一堂课就可以实现的,需要长期的刻意练习。从项目经理转型为ScrumMaster的常见现象是,项目经理戴着ScrumMaster的“帽子”,但其管理风格并没有改变,所以给团队的印象就是换了个头衔而已,常常出现以下情形。
- 站会上,经常见到每个人给ScrumMaster汇报进展,然后ScrumMaster给每个人指示——今天你该做什么。每个人汇报完毕后,会议结束。
- 当团队的Sprint目标没有达到的时候,ScrumMaster自己分析原因,然后做出决定:“我们这个Sprint的目标没有达到,我认为原因是×××,所以,我们应该这样做×××。具体来说,小李,你负责×××;小王,你以后要注意×××。”
而合格的ScrumMaster应该通过问问题的方式来引导团队思考,并由团队自己做决定:“我们这个Sprint目标没有达到,大家认为是什么原因呢?那么大家认为咱们需要采取什么措施改进呢?大家觉得我需要在哪些方面帮助大家,才能达到更好的效果呢?”
|