写作背景

“Scrum Master 负责按照 Scrum 指南的游戏规则来建立 Scrum。他们通过帮助 Scrum Team 和组织内的每个人理解 Scrum 理论和实践来做到这一点。

Scrum Master 对 Scrum Team 的效能负责。他们通过让 Scrum Team 在 Scrum 框架内改进其实践来做到这一点。

Scrum Masters 是真正的领导者，服务于 Scrum Team 和作为更大范围的组织。”

《Scrum指南——2020版》中对Scrum Master（文中简称SM）职责的这段简短而深邃的描述，正如《指南》自己所说：“Scrum 框架故意不完整，仅定义了实施 Scrum 理论所需的部分。Scrum 建立在其使用者的集体智慧之上。”

然而，这种留白也让初学者对SM的具体工作内容感到了困惑，甚至产生了误解。于是，我便想写一篇文章，结合公司B的具体情况来阐述我的理解，以抛砖引玉，让真理越辩越明。

我理解的SM使用说明

自从上个月首阳之后，公众号便一直处于停更状态。但幸运的是，期间能有机会和国内的敏捷先驱吕毅老师坐而论道，受益匪浅。对话中，吕老师提到SM最主要的是要做好两件事：

一、帮助提高团队的自我管理能力，

二、促使团队的持续改进。

深以为然。如果想达到以上这两个目的，SM的具体工作内容（或者说采取的工作策略）应该是因地制宜、因时制宜，灵活调整的。就好比药方，高明的医生即便对于同一种病症不同的人，或同一个病人不同的时期，开的也并非一模一样。

对于SM应当采取的策略，我认为至少要考虑下面这几个因素：

1.  组织环境
2.  团队环境
3. 个人能力

下文也将从上面三个维度对公司B的情况做个大致描述，并讨论其中SM的正确使用方法。

组织环境

本节主要从组织架构和领导层的支持力度两个方面介绍公司B的组织环境。

组织架构对敏捷的重要性不言而喻，吕毅老师更是将其置为首要任务：先做组织架构的调整，再考虑相应角色能力的提升（关于组织架构的设计，有很多优秀的书籍都做了专题讨论，比如《高效能团队模式》、《敏捷组织》、《精益和敏捷开发大型应用指南》、《精益和敏捷开发大型应用实战》等等）。

由于各种限制因素，公司B的组织架构停留在了一个过渡状态：团队已经是稳定的产品团队（相对于临时的项目团队而言），但项目经理这个角色仍然保留着，只不过头衔变为了“PO”或者“PO-X”（“X”以示和Scrum里的PO进行区分）。这种头衔上的“伪装”或者“妥协”，增加了新老角色兼容的弹性，为后面的敏捷转型争取到了难得可贵的心理空间，但同时也为“PO-X”和SM在职责边界上的含糊甚至冲突埋下了伏笔。

换句话说，乍看上去Scrum的三个角色在一个团队里都已齐备，但实际上是PM和SM并存。而且，由于强大的历史惯性，PM无论是在组织架构，还是在沟通渠道上，都有着天然的优势。这种优势对于SM而言，在权力和影响力上都处于被碾压的位置。久而久之，组织便对SM这个角色的认知产生了扭曲（即使发生在组织的在非正式层面，力量也不容小觑），SM被定位为“助理PM”或者“团队助理”。这种认知还会继续影响到对SM的选拔、招聘，以及培养等，敏捷的实施也将因人才的不足或流失而停滞不前，甚至失败。

在这种过渡的组织架构中，SM应该更多的把自己看作是内部顾问。除了帮助团队建立敏捷的框架，还应该让团队成员意识到组织架构的特殊过渡性质，以及对角色的认知偏差。协助PM为转型后的职业规划和重新选择，做好心理以及能力的双重准备。同时，SM积极和领导层保持沟通，向其反馈团队所面临的组织架构上的障碍，配合进行调整和优化。包括角色的职能调整，能力培养，或者需要组织层面提供的基础设施，统一平台，最低质量保障等。

幸运的是，公司B的领导层始终对敏捷保持着非常高的开放程度，对其曲折的探索之路充满了包容和鼓励，所给予的支持和信念也很坚定。这一点至关重要，从某种意义上讲，可以说是对敏捷的实施和推广起到了决定性的作用。

团队环境

正常情况下，SM不应该去解决某个特定问题，而是提高团队自身解决问题的能力。但在不同的团队环境下，SM需要在专家和协助者这两种身份之间灵活切换。这里所说的团队环境，主要指团队对敏捷的接纳程度，以及认知程度两个方面。（未完待续）