ScrumMaster是Scrum团队的敏捷教练。Ken Rubin说，“类似于运动团队的教练，ScrumMaster观察团队使用Scrum的过程，帮助团队提高工作绩效”。教练不是顾问，不提供解决问题的方案，而是支持Scrum团队自己去发现属于自己的最适合的答案。教练犹如一面镜子，反映Scrum团队的真实现状和局限，同时引发团队看到更多的可能性，鼓励团队尝试变革，不断提高。
ScrumMaster指导团队的时候都干啥呢？我们把ScrumMaster指导团队的日常活动概括为如下这五个方面：留意、反馈、引导、教育、和支持。
1. 留意
好的ScrumMaster要眼观六路，耳听八方，注意观察团队的工作方式，仔细思考他们为什么会这样做，想想有哪些诱因。例如，刚导入Scrum的团队经常会出现这样的问题，开发团队不及时更新看板上的任务状态，在站会上说某个任务已经完成了，但看板上的任务状态还是To-Be。如果留意开发团队的工作环境，就会发现团队使用软件工具（例如JIRA）实现看板的功能，开发者需要登录到这个系统上，才能看到看板的状态。不像物理看板，一直竖在开发团队的座位旁。平时这个Scrum管理工具没人去看，也就没人记得要去更新它。简单的说，是可视化出了问题。
2. 反馈
注意观察是第一步，看到问题以后要反馈，这是第二步。ScrumMaster要把自己观察到的情况反馈给团队，帮助他们利用这些反馈改进工作方式。继续上面的例子中谈到的问题，应该怎么改进呢？引用一个案例。在开会前，ScrumMaster Linda请开发者Jack登录到这个软件系统中，在他的计算机上把团队的开发任务的状态显示出来，请大家在这台计算机前围成一个半圆，让大家都看到当前的状态。然后说：“昨天站会，我听到这个任务已经完成，但看板上它的状态还是To-Be。”那几个没有及时更新看板状态的开发者就说：“我马上更新。”上过导入Scrum的培训课以后，开发者知道怎样做是正确的，教练不用批评或指责，只需要告诉团队自己看到的现象，团队就知道该怎样改正了。这就是反馈的作用。
3. 引导
ScrumMaster需要促进有建设性的沟通和协作，帮助团队走向敏捷。《敏捷教练》这本书里有很多关于教练怎样引导会议的案例。这里引用其中一个。有一次在规划会议中，项目经理颇为沮丧地对开发团队说道：“别扯了！我只是想拿到这些故事的数字而已。”项目经理给团队造成一种错觉，以为规划会议就是完成项目管理的工件。他没有抓住要点，召开规划会议的目的是弄明白要做什么，而这必须得先搞清楚它需要多长时间。团队不可能在讨论清楚需要做的事情前就“给故事弄个数字”，而这种讨论往往会涉及软件设计方面的交流。会后，敏捷教练跟项目经理分享了观察到的情况，项目经理很高兴敏捷教练指出了问题。随后那次会议，设计议程的时候，项目经理就预留出时间来进行技术讨论。
4. 教育
ScrumMaster要想方设法鼓励团队学习敏捷，方法包括演示Scrum中的一些实践；分享其他团队使用Scrum的经验；还可以开设培训课程。例如，在一个团队刚刚导入Scrum的时候，可以给全团队做一次集中培训，讲解Scrum价值观，原则和各个实践，演示怎样使用Kanban，怎样用估算扑克估算用户故事点，并分享其他团队的案例供大家参考学习。在运用Scrum的过程中，如果遇到什么特殊情况，也应该开设一些有针对性的专题培训，例如代码重构。还可以在组建了微信敏捷讨论组，分享一些敏捷相关的资讯，提高大家对敏捷的认知水平。
5. 支持
当团队遇到困难时，要鼓励他们，帮助他们保持动力。讲个案例。Amy是一位敏捷教练，他指导的开发团队中有一个小伙子叫David。有一段时期，开站会的时候，轮到David发言，David一直低着头抠他的手指头，说话声音也非常小，几乎听不见。Amy心里纳闷儿：“David以前并不这样，最近这是怎么了？”后来Amy约David在一起吃中饭，并告诉他，自己注意到他抠手指头、说话声音很小。David打开话匣子，说了他的迷茫：继续干下去没动力，换岗或离职又不知道要到哪里去。David问了Amy几个问题，Amy回答了David，帮助David了解到一些信息，包括他当前所从事的技术领域在组织内的重要性，和在行业中的领先地位；其他岗位的工作内容和挑战；离职的补偿政策和风险。Amy又引导David重新认识自己，看到自己的强项，鼓励他在当前这个技术领域坚持下去。最后David说：“我明白了，我要留下来，干出成绩。我该早些找你谈谈的。谢谢你Amy！”
ScrumMaster培养团队，提升团队自身的产出能力，提升团队成员的自我判断能力，帮助团队成员顺利度过从不敏捷到敏捷这个转型的困难时期，让他们走上自己的敏捷之路，最终找到自己的路。在处理ScrumMaster和开发团队的关系时，有两个误区要小心。
第一、ScrumMaster不要越俎代庖
例如，开发团队做单元测试不到位，这在很多组织都是个老大难问题。怎么办？ScrumMaster撸起袖子自己上，秒变tester？不要这样做。这样做会导致开发团队以为ScrumMaster就是负责测试的，自己不必测试，这样的想法反而会导致发布质量下降。再讲一个案例。Amanda是一位擅长测试技术和工具的敏捷教练。她找开发团队聊天“为啥不做测试呢？”开发团队说：“手工测试花时间太多。”Amanda就推荐一个测试工具给他们，有人说这工具不好用，Amanda就坐在开发团队旁边给他们演示怎样使用。Amanda运行了一个例子，告诉开发团队只要把例子换成他们产品需要测试的模块就行了。开发团队一看，原来这么简单啊！Amanda早上花了30分钟给开发团队演示，这个开发团队下午就把第一份自动化测试报告发出来了。后来这个团队坚持自动化测试，一直到产品开发结束。
ScrumMaster的职责是培养团队，提升团队自身的产出能力。这就好比，排球比赛，教练能上场替队员打球吗？郎平带的球队也输过球，你什么时候见过郎平把主攻手换下来，自己上场扣球呢？培养团队，功夫在场外，要演示，要辅导，要答疑，就是不要替做他该做的工作。
第二、ScrumMaster不要监控惩罚
还说开发团队做单元测试的问题。有的ScrumMaster是这样做的，设立测试覆盖率KPI，目标值100%，不达标就扣考核的绩效分数。开始开发团队还抱怨，后来被管理层强力压下去了。谁也不敢再抱怨。但口服心不服啊！管理层要看覆盖率100%是吧？开发者用Excel手工填一张覆盖率100%的报告，和工具自动生成的一模一样。开里程碑会议的时候，微笑着告诉经理“我们的覆盖率达到了目标值。”心里说：“一个星期几十个项目结束，我不信你有精力查下去。”ScrumMaster这样处理和开发团队的关系，对开发团队、对产品都没有好处。
ScrumMaster和产品负责人之间的关系，既是互相制衡的，又是互补的。
先讲制衡。产品负责人的目标是产品，ScrumMaster的目标是培养团队，两个角色的目的不同。雄心勃勃的产品负责人开发产品追求多、快、好、省，难免要对开发团队举起小皮鞭，催促开发团队加班赶工。ScrumMaster要保护团队，使团队可持续发展，要做产品负责人和开发团队之间的润滑剂。产品负责人和ScrumMaster这两个角色设计的初衷就是为了彼此制衡，所以不推荐让一个人兼任ScrumMaster和产品负责人这两个角色。
再讲互补。产品负责人主要负责“目标”--开发正确的产品，ScrumMaster主要负责“方式”--使用正确的方式来实施Scrum，通过使用Scrum帮助产品负责人取得最大的业务成果。只有使用正确的方式来创建正确的产品，才能取得持久的成功。把眼光放长远，优秀的产品背后必须有一直优秀的开发团队。所以，产品负责人和ScrumMaster又是互补的。
以上我用严肃的语言一本正经的讲ScrumMaster的第一个职责：敏捷教练。下面咱们也灌点儿心灵鸡汤，讲点励志故事。我的少年时代，是在学习中国女排拼搏精神的氛围中度过的。在我们那一代人里，没有人不知道郎平。郎平退役后，成为一名职业教练，把美国女排带到奥运亚军，成就了美国女排的奖牌梦，美国女排也成就了郎平作为女排教练的世界知名度。也正是因为郎平执教女排的光辉战绩，中国体委才会邀请郎平回国执教。这才有了当年的“众望所归”。与运动教练类似，优秀的ScrumMaster和优秀产品负责人、优秀的开发团队三者之间互相成就。与之相反，中国某体育运动项目，几十年来，教练换了二十几任，球队就是不出成绩。有网友调侃说：此运动项目的教练可以划分为两种状态：已经下课的，和等着下课的。
ScrumMaster的第一项职责是Scrum团队的敏捷教练。ScrumMaster通过留意、反馈、引导、教育、和支持，帮助团队驾驭敏捷，开发出色的软件。ScrumMaster培养开发团队。ScrumMaster与产品负责人之间既相互制衡，又互补。
