为什么要写这篇文章？

最近看了一些文章，多是关于团队建设的，突然想到自己做了四年多的Master，是不是也有些什么可以拿出来总结和分享的呢？一是看看自己到底掌握了哪些，还有可能帮助到一些朋友们，另外，工作中发现有很多作为Scrum Master的朋友们对这个角色还有很多不解， 所以我给这篇文章起名叫Lost Scrum Master， 包括我， 完全没有接触过相关的培训，也是在工作中不断的摸索和成长，希望通过我的一些经验或者见解能够帮助到大家， 也欢迎大家一起讨论和探讨，相互学习， 共同成长。

怎么解读Scrum Master 这个角色？

我们经常能在相关的文章中看到Scrum Master就是要“保护团队”和“服务团队”。 我想说的是这个解释完全的正确， 可以说是恰到好处， 无可挑剔， 可是大家想过没有对于一位新的Scrum Master能否真正体会到它的含义， 是否就知道在实际工作该怎么处理问题，带好团队， 我想只有Scrum Master（new）有这个发言权。 是不是过于的笼统而不够具体， 这八个字是当过Master并且有经验的同学们经历了很多的困难并解决他们而后的产物。实践证明足够的正确， 但对新手来说缺乏可操作性，实际情况是当他们得到这样的信息后依然的茫然。 那么接下来我会结合我自己工作中的一些经验给大家分享， 希望对大家能有所帮助。

1. 熟悉工作环境

这里指的工作环境主要包含两点： 1）利益相关者，他们的责任范畴以及对你们团队的期望， 无论你在哪个公司哪个部门工作你首先都搞清楚这一点， 那就是在你团队的周围有哪样一些人在持续的关注着团队，影响着团队， 你同样要弄清楚在什么样的事情和情况下谁能提供有效的帮助，比如： 项目经理， 直线经理，产品经理等，这些是你要作为一个Master的基础， 能够帮助你在团队中提高把控和移除阻碍的能力，有个专业术语----生态系统的建立和维护。 这里有个亲身经历的例子， 在每次sprint review中我都把内容准备十分的充分和详尽， 我的初衷就是想在每个点上都要讲的清楚，结果经过几次会议后我发现会议的过程中他们的问题越来越少，我就开始怀疑他们是不是不感兴趣， 于是线下我做了一个调查去收集利益相关者们对这个会议的期望， 结果发现之前的很多内容他们并不关心，而且有些关心的没有体现， 于是在下一次的会议中我做了改进， 他们不关心的内容去掉，丰富他们关心的内容，再添加一些内容是我们想从他们那里得到support的点， 但切记针对这些点要有足够的分析，并给出1~3建议，给他们说清楚以后，让他们去选择会更容易更快的得到帮助，这样，不但会议的效率提高了，大家都高兴了。Work hard 固然重要， 但是要不断提醒自己以及团队是不是朝着一个正确的方向。2）在这个大的环境下的一些必不可少的工作模式，比如说， 在什么情况下要参加什么样的会议啊， 解决bug的流程是什么样的，怎么去解决一个客户的case等，以免在团队中犯一些低级的错误，也能帮助团队在特定的情况下找到风向标。

不管你以后想不想改变环境，你首先要了解环境，关键是你要通过去适应接受它才能更好的了解。

2. 了解团队成员

再复杂的设计方案都是要由团队中的成员来完成，再难的开发语言都是要由团队中的成员来使用的，有了他们才能

有团队的存在，才能源源不断的为客户创造价值， 为公司创造收益，足以证明他们的重要性， 而Scrum team又是

最亲民的团队， 他们的能力情况，性格特点和个人意愿将无形中影响着团队的生产率，那么作为Master有责任

和义务去发现和挖掘团队成员的能力情况，性格特点和个人意愿，目的就是这是成为high performance team

的前提， Master应该结合团队成员的能力情况，性格特点和个人意愿去指引他们做他们可以，适合和喜欢做的事情，

这样他们才能发挥他们最大的优势和潜能并把事情做到极致。上例子，之前有这样一位同事， 让他做什么事情都是

指到哪里就做到哪里， 不多想不多问， 如果说把事情做好为标准的话总是差那么一点点， 关键是他完全有这个能力，

后来不经意间了解到他想接下来的职业规划朝着管理方向发展，从这个信息Master得到一些启发，他是不是更喜欢drive

事情， 而不喜欢被事情drive，是不是之前的一些事情没有给他足够的施展空间， 接下来尝试让他做什么事情只是给

他说期望是什么， 包括需求和完成时间， 其他的内容他可以决定，这一次有很大的变化，虽然没有将事情做到完美，

但也可圈可点， 从积极的工作态度上也有了明显的提高。这不是万能的方法， 例子是想阐述

了解你的团队成员会可以帮助你让团队朝正确的方向变化。

MBTI是一个不错的选择，让你在短时间内能了解每个团队成员的性格特点，用什么样的工作方式对他们来讲是最有效的

非常具有参考意义：http://www.apesk.com/mbti/dati.asp

建立自己的权威--赢得尊重

我一直以为Scrum Master就是一个微型的直线经理， 这也是我的老板这样和我说的，所以在某种程度上Master具备一定power，

只是没有那么强大，比如和money相关的，换句话说， 在某种情况下Master需要带领团队做事情，那么怎么样得到团队成员的

信任和信服是至关重要的，比如：我认识一个团队中的成员在当了一段时间的Master以后他和我说， 团队中有些成员他没有办法hold住，

甚至有些事情的状态他完全不知道， 因为这样事情的讨论都没有让他参与进去， 他很沮丧， 也显得手足无措， 我告诉他说：“

很显然， 你在团队中失去了信任和权威”。 团队中的成员对你失去信心， 这是一件很恐怖的事情，认为从你那里得不到有任何有意义的信息

接下来我们就开始讨论怎么去建立权威的问题， 如果你具备以下三点，那权威自然而然的会站队在你这边，

（一）经验丰富， 比如说我在项目管理上有8年的经验， 一下就会让人感到敬畏， 这点对很多新的Master来讲

可能是硬伤， 多半都是经验并不是很丰富的才会有这样或那样的疑惑，没有关系， 我们在下面几点多加努力；

（二）知识丰富， 这个怎么理解呢？是要了解代码吗？当然不是， 你们想想当团队在讨论解决方案的时候你完全

没有办法参与， 他们会怎么想？ -- “就知道指手画脚， 什么都不懂”。无形中你已经失去了信任，尊重和权威，

所以你所在领域的基础知识，业务逻辑以及大家经常使用的common语言等，帮助你更多的参与到团队，逐渐的建立一些话语权；

（三）解决问题的能力， 这里说的问题指的是团队中可能出现的任何阻碍团队前进的问题， 比如说：他们不知道怎么处理客户的

case， 他们不知道哪个solution是最好的，他们找不到正确的联系人等， 这些看似简单的问题足以让团队无法前进并降低工作效率，

这个时候Master需要站出来支持帮助团队， 不是所有的问题都是需要你直接去解决， 而是你知道应该怎么或者谁来帮助就能解决问题，

然后再让团队在可自我控制的轨道上来。所以这就需要我们Master在日常的工作中不断的积累经验以及有价值的联系人的记录。这里

我要强调一个问题， 这个小节我想说的是通过增强Master解决问题的能力来建立自己在团队中的权威， 但到了一定的程度（什么程度没有办法

衡量， 个人觉得只要觉得团队开始信任你了）以后就要转变观念（From Drive to Guide），不要让团队成员产生对Master过多的依赖性，

Master 什么都可以做得到，这样团队会失去自主性和主动性， 下一节会具体说明团队自主性的重要性以及什么样的行为能够帮助到团队。

（四）服务的心态，这一点才是将Master这个角色演绎好的一个根本，而上面的三点都是对这一点的封装或者说是支撑，你具备以上三点却很难和

团队成员沟通，高高在上，结果还是会失去团队成员对你的信任和信心。始终保持一颗服务的心，我能给这个团队带来什么？我怎么样做

才能更好的为团队服务？经常这样问问自己再付诸于实际的行动，让权威不再遥远。

权威是你带领团队的一把钥匙。

培养团队自主性（Self-organization）

一旦你在团队中有了自信，有了话语权，有了对大环境的把握，有了对团队成员有了了解，这个时候需要做一个转变， 从指导大家做

事情到引导大家做事情，一个字的差异但魔力大增， 以前是你一个人在带领团队做事情， 团队成员都在等Master给出最终的解释，

给出最终的方向，这里就出现了问题：考虑事情的局限性，测试或者开发领域知识的局限性，思想的狭隘，团队的路会变得狭窄，而如果

团队所有的成员都在为这件事情出谋划策， 大家从不同的领域去思考问题会更全面，很多的问题会提前暴露，我们可能会有更多的

方案可以选择， 思考讨论的过程又是知识分享的过程，大家的参与度会更高，他们会更积极的做事情，因为那是他们自己的决定，

有很多很多好处，那么Master 要怎么样做才能让团队有自主性呢？--- 少做决定，多问问题。

少做决定不是不需要了解事情，要了解事情的背景同时你可以有自己的解决方法和思路，但请不要直接说出来；

用问问题的方式去引导大家思考和讨论，如果他们始终没有讨论出方案，再将你的方案拿出来讨论， 或者方案之间的PK；

带领团队去创建团队工作模式

没有规矩不能成方圆， 大家做事的风格各异会造成大家的讨论没有在一个平面上--浪费时间，比如说代码审查这个不陌生的例子，

一个团队成员喜欢用这个工具， 就需要所有的成员去学习使用和适应，明天又有一位同事换了一个工具.... 工作模式持续改进，

每一种方式方法都有改进的空间，所以要带领团队拥抱变化。一个拥抱变化的例子， 我发现有个团队最近开早会的时候， 每个人

都拿着一张纸， 之后我去和他们的Master沟通才得知，他给每个人在本次迭代的任务都打印出来， 解决以前开早会的时候大家经常

花时间去想自己有哪些任务的问题。

工作模式包括什么：

几点开早会

资源的管理

工作流程， Bug 处理， 新功能开发， 代码审查

遇到疑难杂症的应对措施

建立团队的财富库， 包括相关的联系人， 资料的分享等

。。。

要带领团队创建特有的工作模式，并不断丰富改进。 注意：我用的是带领， 不是说Master去

创建， 这个工作模式是大家一起经过商讨定义出来，有些人会问：“这有什么区别？” 完全不同，你去创建一个，

是不是正确的不说， 大家就会觉得那我们照做就是了， 反正没有什么商量的余地， 他们不会自己思考为什么要

这样做？是不是还有更好的办法？而且他们自己想出来的方式方法，他们更容易接受并执行。---- 他们是从内心

买账（buy-in）的， 这就是区别。还要说的是这个定语“特有的”， 意思就是说完成/做好任何一件事情都有不同的方式方法，

但是每个人或者每个团队都有自己的方式和特点，比如说记录任务状态这个事情， 有些团队喜欢在excel中去更新查看， 他们觉得

那样可以快速的看到数据统计信息， 有些团队喜欢用白板的形式记录， 他们认为更直观， 但是他们都能够满足他们的最初需求--

监控团队在执行任务的过程中是否足够的健康。 团队如家庭， 有自己的精神，有自己的习惯，特有的工作模式会让团队有归属感。

我们是不是经常会说：“我们团队在面对这样的情况是那样处理的， 完全可以解决你的顾虑。” 当时内心是不是觉得特别的自豪。

团队能力的提升和平衡

团队之所以存在是因为有事情做， 做事情就需要能力， 那是不是团队有能力把交到我们手里的事情做完就足够了呢， 答案肯定是

否定的，Master需要从两个维度帮助团队的能力提升， 【深度】让专属领域的能力不断增强， 以提供工作效率和团队的整体解决

问题的能力， 比如说：团队以前只能解决自己模块的事情， 能力提高了以后也了解了相关模块的业务逻辑， 帮助快速的定位和解决

问题。【广度】解决团队的能力平衡，要让一块的专属技术领域有2~3个同事能够可以掌握， 这样就提高了团队处理问题的灵活性，

也可以提供工作效率， 比如说：团队中不会有一个人请假了而影响了问题不能解决，事情不能推进。

那么在实践中该怎么操作呢？分享下个人的经验：

在日常工作中收集相关的学习需求， 根据优先级排序， 定期的组织workshop， 邀请外部技术支持或内部解决；

团队内部定期的组织责任人切换，解决专属领域被多人掌握的可能性；

结合个人兴趣爱好来进行分配和调整，让团队能力提升的计划减少阻力；

上面所说的能力提升更多的是从技术层面的，而实际工作中软技巧也不容忽视，软技巧是我们实现技术方案的润滑剂，沟通技巧，

有效的会议，这个需要你在工作中发现这些Gap，并寻求直线经理的support，一起来支持团队建设。

带领团队执行Scrum相关的活动

我们知道Scrum的相关活动有很多， grooming， planning， daily meeting， retro meeting， sprint review。

Scrum master首先自己要弄清楚这些活动的意义所在，并引导大家对此有充分的理解和认识，也就是我们做什么事情

首先都要了解它的目的，意义在哪里，在实施的过程中才不会迷失方向。

这里只重点讨论下持续改进--- 因为我个人觉得这是所有activity中最重要的一个环节，我们做事失败了或者不完美不要紧，

重要的是我们自己有没有认识到这一点， 并且对不足的点有可执行的计划去弥补， 并在下一次迭代中去检查是否已经改进，

Master的责任就是能够帮助团队找到可以提高的有价值的改进点， 并坚持执行和检查结果

---- Follow through and Follow up.

定期的思考

这个也是我最近一年当中才领悟到的， 很多时候我们作为Master经常会和团队一起专注的fighting， 但正由于这样我们有些时候

忽略了方向，忽略了目标。上例子：团队经常会遇到救火的情况， Bug 是一个接一个的来，Master 就会和团队一起去消灭他们，而且

会变的特别的专注， 脑子里面一直有一个念头， 一定要快速的消灭他们， 不能让它影响了我们的KPI， 我要保护团队， 一个或者两个

问题我们可以这样做， 但是问题多了我们要多想想， Master这个时候可以尝试跳出团队， 仿佛站在桌子上在看下面的团队， 问问自己

他们在干什么？ 发生了什么事情？ 为什么会这样？ 这正常吗？ 是不是平时工作中遗漏了什么？ 我们团队哪里出了问题？所以针对

上面的例子， 有可能是我们得到需求是不是模糊的， 或者我们的代码审查环节是不是力度不够等，只有找到根本问题， 你才能解决救火

的场面。 上面只是一个例子， 建议Master可以养成这样一个习惯就是定期的给自己半个小时的时间去思考， 是跳出团队的思考时间， 回忆下

之前团队都做了什么？ 还有哪些需要改进的， 我们接下来会面临哪些困难， 该怎么去解决？？ 等等。

这个过程相当于是Master在为回顾会议提前做准备，重点是一样的，带着问题到会议中来， 充分利用团队力量来思考并改进。

定期思考， 让团队成长， 也让你进步！！

及时沟通 （直线经理和项目经理）

作为Master， 我们经常沟通的经理就是直线经理和项目经理， 也是离团队最近的经理们， 沟通肯定是基于需要的， 那么他们都想

从Master这里得到什么呢？我们来尝试分解下：

项目经理：

确保团队中的成员都为项目贡献出100%的力量， 不断提高生产率；

确保团队能将项目按时按质的交付；

项目中是不是有什么风险；

直线经理

团队中成员的能力和项目需要的匹配程度；

团队中成员的工作状态， 态度是否积极；

作为团队与经理们的接口人我们要定期让他们知道团队的情况， 以确保潜在的风险能够提前被解决。

那作为Master的我们就没有什么需要让他们来满足的吗？ 必须有：

让我们的工作成果能够visible， 目的大家知道。

我们在工作中遇到了解决不了的难题， 需要他们来支持帮助；

沟通让双方（团队&经理们）受益！

通常工作中都会有相关的会议来体现上述内容， Master要提前准备并及时提出， 如果没有相关会议， 最好自己安排， 这个是非常必要的过程。

疑问？

有些朋友可能会问，那Master的目标到底是什么呢？我的答案是让团队里面所有的成员都情愿的Master的事情，做到人人都是Master，

最终在团队中淡化Master这个角色，团队做事会更高效，生产率更高，朝着High Performance 团队迈进，接着可能会问那我能得到什么？

我们把这个问题换个方式描述, Master对我后期的个人职业发展有什么样的好处？我个人的感受是Master可以锻炼两条线上的能力：

项目管理和直线经理，后者偏多。所以你可以得到的是在得到role之前的实战演练的机会。达到个人发展和business value双赢的局面。

总结：

到这里，本文就要收尾了， 我相信大家不难发现一个问题， 怎么我描述的Master更像一个直线经理， 有很多的职能超出了Master的责任范畴，

我的老板曾经对所有的Master说过一句话， Master就是一个只有7~8个人team的直线经理， 除了Salary相关的activity过于敏感的话题，其他的

都可以做， 或者应该做， 我的领悟是， 只有那样， 你才能做好Master这个角色。你才会想的更多， 问的更多，做的更多， 成长的更多，

让事情接近完美。希望这篇文章能够帮助到您！就像在文章开始的时候说的一样，也希望大家一起探讨，共同成长进步！

最后，建议大家对于个人的发展

不要给自己一个明显的框框，结合自己的能力和兴趣尽情的发挥你的想象力！让方向和目标为你铺路， 脚踏实地的走向你的职业顶峰！