前言

接着昨天分享的话题，针对成为 Scrum Master 的经历与想法再进行补充。

大家从标题「更基本的部分」可能也发觉了，这些文章我刻意倒过来写，从最直观可见的，写回一些需要观察与体会的部分，也许这样会更容易掌握。

Scrum Master 的素养

先从《The Great ScrumMaster中文版: #ScrumMasterWay》这本书说起，初次看可以建构一些基本概念，而後随着自己的实际行动，反覆回看书本进行对照，会有不错的带入感，除了审视目前的还缺了点什麽，也可以看看 Scrum Master 之路有了哪些成长。

在书中可以看到关於 Scrum Master 的许多面向，涵盖了基本概念、心态、成长路径、团队经营、变革、工具与技能等，而书名後面的「#ScrumMasterWay」也是本书的重点，以三个层次来总结 Scrum Master 与团队的成长过程，作为进步的指引。此外，第 7 章 ScrumMaster 的工具箱，提到以下的主题，都相当实用，在此作为关键字将其引出，方便读者再从中探寻其他新知，而细节就不再重述。

掌握守、破、离
系统规则
正面想法
引导
教练法
根本原因分析法 (Root-Cause Analysis)
影响地图
Scrum 的大规模化

成为 Scrum Master，阅读这本书是个不错的开始，也推荐团队任何一员阅读它。这本书虽然轻薄，但里面总结了不少东西，我若跟着提一次意义不大，因此接下来我想分享我的观察，从「源头」开始说起。

不忘源头

Scrum 设计精巧，看着那不长的 Scrum Guide 一闪即过，也许没有产生太多的体会，我们很容易直接去执行各个活动，将人员套入划分好的角色，这一方面也是社群有充足的资源可以参考，也不时会有各种新方法的分享，Scrum Master 或团队若想尝试都是好事、都是行动力的展现，但是团队本身拥有多少的基本功，对於更底层的源头有多大认识，反而是容易被忽略的。

所谓更原始的层面，例如：团队沟通、团队当责、时间掌控、主动学习、不放弃的精神。

够原始了吗？不！再往前到「人」，一群「人」每天穿梭在团队当中，与自己合作着，但又有一群人是不是被忽视了？特别是我们都专注在所谓 Scrum 的活动上。谁呢？－－「利害关系人」(Stakeholder)。

利害关系人的范围很大，端看我们站在哪个角度来看它。我们每天会与团队成员接触，却不一定与客户、老板、其他部门的成员接触，他们可能在特定会议出现，但在第一时间团队是否就识别了他们的愿望？以及後续的行事是否有持续考虑到他们？不光说工作生涯，就在求学阶段也常常看到利害关系人被忽略，他们偏偏又是成事的关键。

有些值得反思的问题，团队或我们自己，对於利害关系人有多了解呢？他们真正想要的是什麽？他们与我们的何时交流？我们又是如何与他们交流？我们要交付的价值确切来说是谁的价值？这些，在还没有执行 Scrum 之前就很重要，倘若之前没有到位，跑了 Scrum 应该会有被重击的感觉，体会到原来一直都有落差存在，过去却这样看也不看的冲过去。不过我们也不用怪任何人，毕竟各种活动、方法论实在是太引人注目了，一不小心就会一直追求，想要把新的方法不断带进来，可惜却一直没有掌握到更基础的关键。

当然了，身为软件团队，专业技能也是基本功，也是想要有所成果需要回头审视的源头，好不容易知道客户真正想要什麽，但碍於技术上限无法达成，又是另一种可惜了。

我在前面的文章「Scrum 也自然吗」也提到过，大家可能对 Scrum 抱有期望，以为导入後自然会变好，却常常忽略了导入前早就存在的问题，而在 Scrum 帮我们暴露问题之後，我们的下一步又是什麽呢？

作为引导团队的 Scrum Master，时刻回首到更基础、更贴近来源的议题上，也把这个「很小的」大观念带给团队，免得白忙一场。

随时学习

从铁人赛第一天到现在，里面含有相当多需要学习的部份，如果我们把视野扩大，看向整个铁人赛，又有数不清的知识点与学习路径。

Scrum Master 的工作内容是如此多面，从各点展开也有非常多的主题，这需要积极的自主学习能力。好在，现在的学习资源相当丰富，也早已突破许多时间与空间上的障碍。我同时鼓励 Scrum Master 掌握(了解)部分团队技能，以软件团队而言，可能是团队使用的程序语言、框架、架构，以及相关的领域知识，如此我们更能以相同的语言与团队沟通。

然後，你就会学不完了 (喂)。

多重身分

这个议题在《The Great ScrumMaster中文版 #ScrumMasterWay》一书也有所探讨，描述了 Scrum Master 兼任团队成员、兼任 PO、兼任主管与跨多团队服务的 Scrum Master。很自然的，没有绝对好坏，书中确实给出每一种组合的优缺点与其结果，最终仅推荐 Scrum Master 同时支援两到三个团队的方案。

视组织规模，有时发生兼任的情况是难以避免的。这种兼任带来的身分重叠确实会有一些困扰，一个直观的例子是，带有主管身分的 Scrum Master 可能成为团队成员无法畅欲所言的原因，更不乐见的是，也许主管本身就是阻碍。但同时这也会带来一些机会，拥有管理权限的主管，会更有力道推动变革，也可以直接调动资源，给予团队更快更实际的支援。

多重身分是一种取舍，以管理手段介入也可能引发更大的反弹，产生一种武断的感觉，而主管能否倾听团队本身就是管理与领导上的要事，不应该等到兼任 Scrum Master 才来考虑，这麽说来，又是一件发生在 Scrum 之前的「基础」呢。

所以说多重身分是好是坏？很难说，若现况需要兼任，先把它当作一种机会，只是记得背後都有取舍，假若在过程中我们确实发现到问题，那麽专任的 Scrum Master 就应该出现在团队发展的道路上。

後记

任何事要做好都不容易，与全天下的 Scrum Master 们说声谢谢！