敏捷其实很简单（6）神坛上的Scrum Master

#敏捷其实很简单-回顾

因为最近工作的原因，所以有段时间没有更新这个系列的文章了。其实除了时间原因，还有就是想停下来思考一下，后面要怎么写，如何能够从一些新的角度来剖析敏捷，和各位敏捷从业者一起思考敏捷现在的状态和未来的趋势。经过几天的思考和跟其他一些朋友聊天的收获，觉得其实还是要从题目开始，从简单入手，能够通过一些简单的描述和案例，从一些大家平时所忽视的角度给大家讲一下敏捷，从而能够和各位读者一起进步，共同理解敏捷，思考敏捷吧。

神坛上的Scrum Master

为什么要起这个奇怪的名字，因为作者曾经在某大型设备商担任过3年的Scrum Master,从15人的团队到3个团队多达45个人，期间经历了兼职的SM和全职的SM，也可以算小有心得吧。但是最大的一点就是，在很多敏捷从业者，或者转型期的企业里面，对SM的期望往往是很大的，而在Scrum的概念里面，也对SM赋予了很大的责任。
那么经典的Scrum Master都需要哪些role呢？

看了这副图片之后，怎么样，一般人当不了Scrum Master吧。诚然，Scrum Master实际上是一个复合型人才，其实产品经理，项目经理，team leader等都不一定能够成为一名好的Scrum Master。那么都需要什么技能才能做一个好的Scrum Master呢？

怎么样，Scrum Master需要的技能还很多吧。这样的人才，在团队中应该是很重要的位置，而且能够起到足够重要的作用来帮助团队达成目标，推动团队成员的发展和技能提升，同时帮助组织来实现愿景，应该是在整个组织中，都是神一般的存在吧。
所以这也是Scrum框架中，为什么Scrum Master如此重要的原因。现在很多企业转型的时候，往往对Scrum Master赋予了很高的期望，希望他们能够帮助组织转型成功，保证团队高效交付，提升团队成员技能水平等。但是实际运营中，却发现并没有能够达到真正的效果，这是为什么呢？
下面读者从一些切身的体会和实际的案例中，来帮助大家分析一下，本来应该是在敏捷转型中起到重要作用的Scrum Master为什么走下神坛，没有大家期望的那么”神”。

- 没有授权导致先天弱势：

在经典的scrum框架中，scrum master作为一个服务型的团队成员角色，是没有授权来管理和领导团队的，所以他如果想辅导，教练团队就只能依靠一些软技能来达到目标，比如说我们常说的“话聊”，还有一些引导技术和自己掌握的理论知识。这实际上对于个人智商，情商，沟通能力等要求很高。而在中国的传统文化中，大部分人可能还是习惯于被领导和管理的状态，也就是说习惯于那种传统的强管理模式，那么在这个时候，如果Scrum Master没有授权，只是依靠个人魅力来进行工作的话，就是事倍功半的效果。笔者原来的公司就是这样，一开始大部分Scrum Master都是由团队的开发成员担任，而在实际工作中，其他的开发成员面对SM的一些辅导和引导的时候，总是有一种“你又不是老板，我为什么要听你的”的想法，导致工作很难开展。那么如何解决这种问题呢，其实可以尝试以下几种方法：
1. 身体力行，SM可以实际的解决一些团队在日常工作中遇到的困难，特别是一些技术上的，来实际的给予团队帮助，从而让自己获得一些实际的领导力和权威，这样以后说话大家可能也会信服。
2. 引入授权者，笔者在以前的一个团队中，发现团队成员不能按时更细腻burndown chart，每当问起的时候总是有各种各样的理由，后来笔者将team的manager(由于公司文化，每个scrum team还是有一个manager的)引入到每日站会，他的任务就是每天关注一下team的burndown chart,2个sprint之后，团队能够达到自觉更新burndown chart的目标了，这个时候Scrum master再请manager quit出每日站会。
3. 制定一些reward，某些时候Scrum Master引入一些实践到team中的时候，一开始总是发现抵触很多，这个时候Scrum Master可以尝试一些奖惩措施来达到目的，笔者以前的一个team每日站会经常有人迟到，于是笔者在一次retro会议上提出，是否下个sprint站会再迟到的人就交一部分钱到team的公共账户，然后这个账户可以在以后的retro, review等会议上买一些食品让整个team享用，然后在下个sprint的第一天，笔者就故意迟到一次，然后交了罚金，后来又有几个人迟到并被惩罚之后，就再也没有人迟到了。当然必要的奖励也是好的，比如说某些人在scrum的流程上表现的好，也可以给予一些奖励，从而鼓励团队更好的努力。

- 有了授权先天强势：

有的人要问了，既然没有授权SM很难做，那么我们就给他授权好了，很多企业转型的时候让产品经理，项目经理等担任SM就是这样的做法。这么做，SM实际上具有了一部分管理者的角色， 跟Scrum的理念是不符合的。而随之带来的问题就是团队对于SM的认知不清楚。举个例子，当你跟团队成员聊天的时候，他不知道是在跟项目经理说话还是跟SM说话。因为在团队成员的心目中可能对于这两个不同角色的人的发送和接受信息的态度，状态都是不一样的。虽然这样，很多举措可能会更“快”的推行到team中，但是team往往是被动接受，而不是主动理解并且执行，会导致实际上团队有一种给scrum master打工的感觉。一个典型的例子就是，很多项目经理转型的SM经常问我，怎样才能确定站会是团队成员自己要开的还是给他开的，我的办法是，你请上一周假，然后不指定谁来组织站会，看看团队是否还每天开站会。
那么如何解决这个问题呢？
1. SM最好不要具有多种角色
2. 如果是项目经理等转型而来的SM，一定要经过一些培训和评估，看看他是不是真正的适合做SM这个角色。
3. 在retro会议上，引导团队成员阐述对SM的期望和看法，然后SM朝着这方向努力。

技术专家能当好的SM？

技术专家在团队中往往是很重要的角色，他们也往往具有一些领导力和权威，那么他们能成为好的ＳＭ么？答案是可以，但是要摒弃掉一些技术专家的习惯。

1. 不要过多的参与团队的技术讨论。这个是技术专家在做SM时候经常遇到的问题，就是在planning和站会上经常技痒，会参与到具体的讨论。要知道SM是不需要关注技术问题的，他只是保证流程和团队的运营，如果你过多的参与技术讨论，大家会觉得SM过多的参与到团队的日常工作特别是技术开发中，这样会让团队成员以为SM为团队的中心，不利于SM辅导团队。
2. 不要越庖代俎。有些技术专家的ＳＭ在开planning会议估点的时候，经常会主动说，这个ＵＳ几个点就够了，当然，实际上可能也是相对准确的，但是这样的话会导致团队成员不主动估点，最好造成有ＳＭ来决定US的点数，看起来好像效率高了，但是实际上对于团队的成长起到了负面作用。

以上是我个人总结的一些关于SM的看法和经验，可能会有些片面，也希望大家能够多多评论，给予你们的宝贵意见。在此感谢。
同时也预报下一篇文章是讲一下Scrum Master的工具箱。