Scrum Master:职位还是角色?

阅读数:6277 2014 年 1 月 29 日

几个月前,我在一次本地敏捷用户组聚会上,加入了关于 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目前是密苏里州圣路易斯 TriZetto Provider Solutions 公司 IT 总监,他负责若干敏捷和看板产品开发团队与应用架构。自爱德华·尤登(Edward Yourdan)时代起,他就醉心于流程。他在职业生涯中,曾对开发组织进行过若干方法论改革,包括统一软件开发过程(RUP)、精炼统一过程(EssUP)和敏捷。他热爱过程改进,寻求更好、更快、代价更低的软件开发方式。他目前正热衷于敏捷环境中的管理方式。

原文英文链接:Scrum Master: Position or Role?


感谢侯伯薇对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论