当ScrumMaster成为障碍……

如其名所示，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 ...