传统到敏捷的转型中，谁更适合做Scrum Master？

目前，越来越多的IT企业和团队开始在做敏捷转型，而迈向敏捷转型的第一步，往往就是组建一支敏捷的团队，在Scrum的敏捷团队中，Scrum Master起到了至关重要的作用，那么由传统向敏捷转型的过程中，原团队中谁更适合担任这样的角色呢？

本文主要讲述的是从传统到敏捷Scrum团队转型中，对Scrum Master这一角色的分析，关于Scrum等其他相关内容等不在本文讲述范围内。

如果想要知道谁更适合，首先要知道Scrum Master究竟是干什么的。

Scrum Master作为Scrum框架中的三个角色之一，一直以来也没有一个很好的中文翻译，而且Scrum Master这个词，从字面意思上理解不仅有精通还有控制的意思，而Scrum Master的角色职能上又没有实际的权利，所以单从词本身上来看也是充满了矛盾色彩。

按照Scrum指南中的定义，Scrum Master是负责帮助团队理解Scrum理论、实践、规则和价值的。对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum 团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团队的互动方式来最大化 Scrum 团队所创造的价值。

Scrum Master的职责不仅在团队内部服务于产品负责人（Product Owner）和开发团队，还服务于组织，如下：

Scrum Master 服务于产品负责人包括：

• 确保 Scrum 团队中的每个人都尽可能地理解目标、范围和产品域；
• 找到有效管理产品待办列表的技巧；
• 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
• 理解在经验主义的环境中的产品规划；
• 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
• 理解并实践敏捷性；
• 当被请求或需要时，引导 Scrum 事件。

Scrum Master 服务于团队：

• 作为教练在自组织和跨职能方面给予开发团队以指导；
• 帮助开发团队创造高价值的产品；
• 移除开发团队工作进展中的障碍；
• 按被请求或需要时，引导 Scrum 事件；
• 在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。

Scrum Master 服务于组织：

• 带领并作为教练指导组织采纳 Scrum；
• 在组织范围内规划 Scrum 的实施；
• 帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发；
• 引发能够提升 Scrum 团队生产率的改变；
• 与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性。

除了 Scrum指南 ，Kenneth Rubin还给出了Scrum Master的职责范围包括：教练、服务型领导、过程权威、“保护伞”、“清道夫”、变革代言人，而且具备见多识广、善于提问、有耐心、有协作精神、保护团队、公开透明的特征（更多解释见《Scrum精髓：敏捷转型指南》第10章的内容）

所以，综上可以看出Scrum Master作为一个非传统团队中的角色，是一个需要多项技能和能力的相对比较全面的多面手，对能胜任该角色的人员也是有一定的要求的。如现在比较流行的T型人才（在知识结构上有深度也有广度），甚至多专多能。

一般来说，在传统团队，主要的角色有：项目经理、技术经理、QA、测试人员、开发人员等。如果单从原教旨主义来看，传统的角色可能都不可以做Scrum Master，但Scrum指南也并没有指明只有什么样的角色才可以做Scrum Master，只要是符合Scrum Master的能力要求的不管你之前是什么角色是都可以。那么现在的问题，可能就不再是谁可以做Scrum Master了。

笔者曾在一段时间内辅导两家企业做敏捷转型，这两家公司都比较小的创业型公司。在转型初期，其中一家企业A，在内部探讨后决定Scrum Master由原团队中技术比较好的成员担任，该成员在主要担任的工作有开发、需求讨论和运维等工作，在作为团队的Scrum Master后除了做之前的工作外，也同时担任着Scrum Master的工作，由于人微言轻等因素，在推动Scrum的会议和实践时受到了多方面的阻塞。而另一家企业B，正好相反，他们的Scrum Master由他们的CEO担任，所以可想而知，在实施Scrum的过程中非常的“顺利”，但是，他们CEO还同时担任着产品负责人的角色。在过程中团队常常分不清他是Scrum Master 还是 产品负责人，一言堂的局面也是在所难免的。

上述的情况都不是从传统团队转型到敏捷团队的好例子，在转型过程中出现问题的情况也还有很多，这基本上都源于转型团队对Scrum Master这个角色理解上的偏差，对于这种新角色，看似传统的任意角色都不适合但又好像都可以担任，“Scrum Master”本身就有一定的矛盾性，从“服务型”或“仆人式”这样的描述来看好像是没有管理权利，甚至低人一等的感觉，但是Scrum Master确实管理着Scrum的过程，为团队创造最大的价值。那么从传统转敏捷后，到底谁更适合做Scrum Master呢？

解决方案

从传统团队转敏捷，担任Scrum Master的分别有：项目经理、技术经理（架构师）、QA(质量保证–QUALITY ASSURANCE)、测试，这些都是笔记见到和了解到的。就如分析中所说，在Scrum中没有指明什么样的角色才适合做Scrum Master，如果非要从中选择一个相对来说更适合的角色，我们大致上可以以Scrum指南上对该角色的职责（服务于产品负责人、服务于团队、服务于组织）描述来界定的，并给出上述4种角色的各自优势和不足（注：由于每个公司对角色的职能定义不尽相同，下面的分析仅以笔者认知为准）。如下：

可能，有些读者对于QA的这个角色，可能会有人不太熟悉，这里要特意介绍一下。

QA，在目的上是，为了使管理者和项目人员客观地了解项目执行的活动和工作产品与既定的过程要求和产品标准的符合情况。

QA角色的特点大致有5个方面，即对质量体系实施的作用、对项目QCD(Quality, Cost, and Delivery)的作用、对管理者的作用、对企业文化的影响、对客户的影响，具体如下：

综上所述，QA的角色所对接的不仅仅是管理者（组织）和项目中的人员（团队），也对客户（需求or产品负责人）同时也是处理过程改善的过程推动者，相对于其他角色，在Scrum Master的职能的契合程度上最高的，而且当一个团队从瀑布到敏捷的转型过程中，QA保障了过程的实施有效性及延续性。所以，QA转为Scrum Master，是笔者见过最多的，也是最成功的。此外，笔者也对其他角色的转型占比给出个人倾向的排序：测试>项目经理>技术经理。如果在传统的团队中还有BA（Business Analys）这样的角色，笔者认为BA的优先考虑程度要高于测试（因为一个合格BA的职责范围包括业务和技术等多方面），所以最后的排序为：QA>BA>测试>项目经理>技术经理。读者可根据自身情况作参考。

然而，虽给出了一个排序，但在真正的团队转型过程中，不能是只单纯的把某一原角色转变成新角色就可以了，还要配合着能力和思想上的转变，不管是哪种角色，如果想成为一个合格的Scrum Master，都需要从“心”出发，除了提升自我技能外，还要从思想 （同情心、同理心、服务型等） 上根本发生转变。

最后，我们经常会说“没有银弹”，确实如此，在实际的工作中，哪怕一个Scrum Master完全符合了Scrum Master的职能角色定义，也不见就OK了，符合定义可能只是会让Scrum Master看起来很Scrum Master，不见得团队就能成为一个优秀的高效能的自组织团队，也不见得所有的过程和问题都可以得到完美实施解决，因为没有真正的完美，只有是在实践中寻找、在总结中完善，在提升中蜕变后才能变得完美。别忘了，你们可是敏捷团队啊，把你的想法落实到迭代中慢慢探索适合自己团队的道路吧。

参考附录

《Scrum精髓：敏捷转型指南》

《The Scrum Guide》