几个月前，我在一次本地敏捷用户组聚会上，加入了关于Scrum Master的同行交流。我在会上的发言造成了一些小骚动，我问的第一个问题是“各位所在公司采用全职Scrum Master的有多少？”出席的公司代表们表示，他们都有全职Scrum Master。于是我接着问了第二个问题“他们做些什么工作？”也许我的提问方式已经暗示了雇佣全职Scrum Master比较奇怪，因为当时我在现场经历了几次鸦雀无声的片刻。除了我的同事，其他大部分人都奇怪地看着我，好像我有三只脑袋一样。最终，他们还是迁就了显然没有好好学习的我，用《Scrum指南》里关于Scrum Master的描述来回答我。当我说我们已经用不着全职Scrum Master时，他们都震惊了。其实我还没说，我们从来就没有用过全职Scrum Master。
《Scrum指南》对Scrum Master的角色做了一般性的描述：负责指导、训练、指引和消除障碍。对刚出道的Scrum团队，这些事情要耗费一些时间。还不熟悉Scrum的团队要通过书本来学习Scrum，需要有一个人来负责指导、训练、指引和消除障碍等工作。可是，交付团队成长起来之后呢？指导减少，训练减少，尽管仍然需要在持续改进方面加以训练。指引还是必需的，不过这只占用很少的时间。随着团队学会了自己处理障碍，障碍也会减少。如果某个团队成员的全职工作是负责指导、训练、指引和消除障碍，而所有这些工作的工作量只占用他们10%到25%的时间的话，那他们多余的时间干什么呢？
所以，我们是这样操作的。我们也从Scrum起步，但并没有严格照搬书本。我们的项目经理同时负责好几个项目，所以要与多个项目团队协作。我们首先对项目经理进行敏捷培训。他们中有些参加的是高阶课程，有几个甚至拿到了Scrum Master和PMI的Agile Project Managers认证。于是，这些项目经理成了我们第一批Scrum Master。因为资源有限（我们的项目经理还没有团队数量多），或许也是有点先见之明，我们没有立即让Scrum Master去负责单个团队。没错，我们从一开始就违反了Scrum原则。一般来说，每个项目经理负责两个团队，他们承担着Scrum Master的角色。所以他们很忙，但是还能应付。正如大家能想象到的，他们的职责就是对团队进行Scrum指导训练、指引Scrum仪式并消除障碍。在前九个月甚至一年内，我们一直都是这样运作的。
很幸运，在这种运作方式之下，我们的Scrum团队成长起来了。当我在与员工的一对一谈话中不断被问到项目经理（注意，他们没被称呼为Scrum Master）在团队中的作用时，我意识到，我们将项目经理作为Scrum Master的做法开始出问题了。交付团队成员觉得他们被不同的人过度管理了。他们已经有自己的职能经理（functional manager）了，现在又多一个Scrum Master，而且后者不是交付团队中的成员。
因此，我们在架构上做了一些改动。我们允许各个交付团队在内部选择自己的Scrum Master。这个Scrum Master仍然作为全职的交付团队成员，不过他同时还要负责指引Scrum仪式，并在出现障碍时作为第一联络人。那项目经理怎么安排呢？首先，他们还是项目经理，负责一些项目管理工作，譬如进行跨团队协作等。不过他们还被委以敏捷教练的职责。这样一来，敏捷训练不再是我们强加给交付团队的任务，而是成为一种应要求提供的支援。这样效果还不错。那些在敏捷方法和思想上已经成熟的团队，不再有被过度管理的感觉；而那些仍处于成长中的团队，他们也有人可以请教。
在我们继续成长的道路上，还有一个小小的转变。我们把项目经理（Project Manager）提升为程序经理（Program Manager）。所以，他们现在要负责跨团队协作的行动，比如那些跨产品以及涉及多个交付团队的项目。我们还在管理汇报上做了调整，我们把“职能经理/上级”改为“交付团队经理/上级”。后者我们称之为交付经理（delivery manager）。另外，现在是由交付经理来负责敏捷训练与指导了。我们现在仍然这么做，尽管想法古怪，但团队一直交付正常，所以似乎效果还不错。
对我们来说，Scrum Masters刚开始是个职位，然后随着我们在敏捷上的成长，演变成为一个角色。我们将Scrum Master的职责分成两个部分，一是训练与指导，另一个是指引与消除障碍。让团队进行自我管理，允许他们可持续成长，这样运作很有效，因为训练不再是强加给他们的任务，而是应要求提供的支援。而且，很多团队采用轮流担任Scrum Master角色的办法，这有利于让更多团队成员体验这个角色。此外，我们发现，交付团队里的所有成员都可以担任Scrum Master。比如，我们的业务分析师、开发人员、QA测试都当过Scrum Master。我们还发现，Scrum Master还时常在交付团队内部兼任着敏捷训练与指导的角色，因为那些有兴趣担负Scrum Master角色的人，往往也对学习敏捷原则感兴趣，他们愿意在团队里分享学习所得。
最后，让管理层高兴的最重要一点是，用较少的人完成同样的工作量。我们有16个交付团队。不采用专职Scrum Master，让我们腾出了16个人及其相关预算。正是这样，我们才得以拥有16个交付团队，而不是13个，我们需要这些多余的人员去填充真正有意义的角色。
实际上，我这篇文章是想提醒正在走向敏捷的各位。如果你雇佣一大把全职Scrum Master（就像圣路易斯这里一样），你需要有一个应对方案，以便在交付团队成熟以后知道该怎么做。至少在这里，大部分受雇的Scrum Master具有项目管理背景。这没什么错，但正如我一再提到的，要准备好回答“现在如何安置这些曾经作为Scrum Master的项目经理呢？”这个问题。
作者：Brian Lawrence
