当 ScrumMaster 成为障碍……

  • Vikas Hazrati
  • 郑柯

2009 年 12 月 19 日

话题:敏捷文化 & 方法

如其名所示,ScrumMaster 是 Scrum 过程的守护者。作为变更的代理人,他支持自己的团队,并将 Scrum 在组织中广为传播。他消除障碍,帮助团队不受干扰,以确保团队的正常运作。然而,在某些情况下,敏捷团队能够感觉到:ScrumMaste 已经成为了最大的障碍。

Siddharta描述了一个在离岸团队中常常出现的场景,文化层级和传统的沟通策略形成了这样的场景。其中,ScrumMaster 最终成为了瓶颈,阻挡于团队和客户之间。

他指出:

很多团队都不愿意让团队成员直接接触客户,甚至产品负责人都不行(尤其是他们处于远程环境的情况下)。因此信息流就会是这样:

你 <->ScrumMaster <-> 产品负责人 <-> 客户

Tobias Mayer对此做出回应,同时指出:如果 ScrumMaster 成为了信息中间人,那么问题的根源并不在这里。

[这是] 一种“命令与控制”的简单管理风格。将某人称为“ScrumMaster”并不代表他就有这个资格和能力,尤其是这个人根深蒂固于旧有的思维方式,而且没有接受指导以改弦更张,那就更是如此。

Jaibeer Malik回应了 Tobias,他认为原因可能出在敏捷的实施和遵循方式上。他强调:沟通是敏捷流程的基石,团队所有成员都应该可以同团队中任何人沟通,而不需通过 ScrumMaster。

Roberto Fasciolo 却认为:ScrumMasters 陷入旧有的工作方式是另有原因。他观察到下面的问题:

  • ScrumMaster 也要对 sprint backlog 上的工作条目做出承诺:当 ScrumMastery 也成为团队成员的一份子时,这种状况尤其普遍。团队只好同意他的意见。
  • ScrumMaster 直接告诉团队怎么做,而不是给出指导:当 ScrumMaster 以前做过项目经理时,这种状况经常发生。其后果就是:团队可能完全依赖其 ScrumMaster。
  • ScrumMaster 成为团队和产品负责人之间的代理:这种情况类似于Siddharta提到的状况,而且在离岸团队中非常普遍。

Mike Cottmeyer 补充道:如果ScrumMaster 仅仅负责记录障碍,那么他就是障碍。一个优秀的 ScrumMaster 不应只记录和移除障碍,他还应该成为预测者,能够预期可能发生的问题,并和团队一起找出隐患。

Cesario Ramos描述了另一种有趣的状况,其中 ScrumMaster 太过深入于团队的工作细节,而没能完成 ScrumMaster 应该完成的任务,从而成为了关键路径上的障碍

这里有意思的地方是:ScrumMaster 在着手“有价值”的项目任务。他或她试图完成其他团队成员手上的工作所依赖的任务。甚至可能发展到:ScrumMaster 感觉到,如果他 / 她不参与进来选择那些重要或困难的任务,团队就无法完成当前 Sprint 的工作。

Boris Gloger也有一个类似的故事要讲,他指出ScrumMaster (SM)不是指超人(Super Man--SM。如果 ScrumMaster 没有正确履行自己的指责,或是想同时担负多个与其主业无关的职责,那他就已经成为了团队的障碍。

因此,有很多状况下,不管是否有人发现,ScrumMaster 都可能已经阻碍了团队绩效的发挥。关键在于及早识别出这些状况,并在有希望的时候尽快纠正。

查看英文原文:When ScrumMaster Becomes the Impediment ...

敏捷文化 & 方法