如其名所示，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 都可能已经阻碍了团队绩效的发挥。关键在于及早识别出这些状况，并在有希望的时候尽快纠正。
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论