前言

今天来部份自我介绍，聊聊身为 Scrum Master 的一些经历。一如系列文章的初衷，希望能触及团队任何成员，从而引发思考，因此今天虽然谈 Scrum Master，但欢迎大家皆以 Scrum Master 自居，让它不仅是角色，更是一种精神。

与敏捷的缘份

我第一次接触到敏捷是在大学时期，参加了以「软件工程」为主题的短期校外课程，由於时间有点久远，已经忘记当时是否有看到更详细的课程介绍，总之课程开始时就带出了敏捷。至今最有印像的大概就是那张由海报纸构成的看板，与各种颜色的便利贴了。

没有适当「学以致用」的机会相当可惜，这就发生在我第一次接触敏捷之後，在当时并没有特别拿它来用的时机，接下来与敏捷的接触就只剩下一些研讨会。又过了几年，到了工作职场，有幸参加相关培训，再一次拿起敏捷，而後身为 Scrum Master，自己投入更大量的时间学习，透过阅读书籍、看着各位大神的分享，并一步一步实践在团队上。

缘份就是这麽奇妙，谁会想到今天会成为 Scrum Master，然後把这些经历写成文章呢？

Scrum Master: Day 0

什麽？明天就是 Scrum Master？虽然参加过相关课程、读过书、听过分享，但明天就上阵了，首要目标是向团队成员传教，传什麽呢？自许是传敏捷精神。

幸运的是，在我进到公司前，就有部份成员曾经尝试过，而随时代累积的一些处事习惯也多少有敏捷的影子，这麽说来并不是从零开始，我要做除了是为新成员说明，更是要重新燃起全员对敏捷的热情，这说来简单也困难，为什麽敏捷之火会变小呢？透过观察，我得到一些启示，但这边卖个关子，我多少把它分摊到各篇文章去了。

於是怀着感恩的心，已经有前人铺陈了，现在做来应该会更为轻松。

是吗？也对也不对，总之我还是准备了课程，从最单纯的 Scrum 介绍，用自认为白话的方式表达 Scrum Guide 并反覆提醒敏捷精神。

Scrum Master: Day 1

随着课程开始，我就带出我的想法，告诉大家，今天是来「再」次敏捷的，一来之前内部已有基础，二来我认为敏捷应该是天生的，留存在大家的行为模式当中，这个观点我在之前的文章「自然而然的敏捷导入」与「Scrum 也自然吗」分享过。

於是我这麽解释 Scrum：「Scrum 提示我们事情本该如何做」。

并且强调了两件事：

1. 了解背後的含意，远比你背下名词有用。
2. 东西总是变动的，会持续进步，敏捷 / Scrum 也不例外。

当然免不了的就是基本的名词介绍，从常见的 3355 展开，角色、产出物、活动、价值观，再到三大支柱。并且介绍了 User Story 的撰写技巧 (INVEST)、Story point 估算的概念 / 方式 / 背後真正的价值、Daily Scrum 应该怎麽开 / 用意是什麽、Review 的正确态度、Retrospective 的重要性等，并时不时抛出开放式问题，希望同学们能够反思。

误打误撞的引导

姑且说当时的我是一位有「勇气」的新手 Scrum Master (自己说…)，对於引导这门艺术并不熟悉，但恰好我问了一系列的问题，目的是要引发团队成员反思，找出个中盲点，我的出发点很单纯，只是想让成员自己找到答案，因为自己找到的才是自己的，我给出来的答案并不见得适合所有人。

现在看来是一种引导的展现。透过问题引导团队思考，在这整个敏捷化的过程，有什麽谬误、好处、坏处，过去面对什麽问题、接下来想怎麽改善等。

然後团队就当机了。

欸？故事是这样接的吗，是的，引导是引导，但有些问题本来就很难，除了更多的技巧与耐心投入，也多给团队一些空间吧！

导入的疑问

虽然对我来说，在观念上完全没有冲突，如同我认为 Scrum 很自然，所以也没什麽导入不导入的，我们需要了解需求、需要产生 MVP 来提早取得回馈、需要随时检视并调整，这也许跟我从小时候开始接触敏捷有关。

此外，还有一件非常幸运的事情，想要执行 Scrum 的想法源自高层，所以我不需要再向上说服。

但对於团队成员，即便没有强烈的表达，对於「怎麽多了一些活动？」、「为什麽要多开这些会议？」、「为什麽说 Daily 不是单纯在报进度？」、「为什麽要一次找这麽多人讨论？」诸如此类的疑问多少还是有的。

我选择把它辨别为「疑问」而不是反弹，因为我相信这是因为还不熟悉 Scrum 活动背後的精神产生的副作用，作为 Scrum Master 面对这些疑问，需要反覆解释，提醒这些活动背後的目的、精神与价值。Scrum 是来帮助我们，而不是拿来增加工作量与烦恼的。

Scrum Master: Day N

光说不练没什麽用，很快的我们就投入第一次冲刺，也许与多数团队不同，我们直接以 Trello 作为虚拟看板，就这麽跑到现在。

Scrum Guide 内提到的活动全部执行，从「守」开始，这当然要感谢团队成员的投入，各活动执行的熟练度也越来越高，甚至我们还可以远距完成所有的活动 (未来再分享)，一切逐渐步入正轨，…… 除了 Burndown Chart 的变化不太美观之外。

嗯？Burndown 为什麽 Burn 不了呢？

这一时半刻说不清楚，每个团队遇到的问题不尽相同，关乎到企业、团队与成员的文化、背景、技能，这也是 Scrum Master 可以发挥价值的所在，短期视自身能力进行救火，中期引导团队找出问题并改善，长期形塑自我管理与成长。当然，就算自己不是 Scrum Master，这些事情完全是任何成员可以主动进行的，就在我们看到 Burndown Chart 投以需要改善讯号之时，这个透明也应该随之引发检视与调适。

反思：在风眼当中

我会这样比喻，一位充满热情、活力满满，希望让团队重拾敏捷的「变革者」，透过不断观察并推动各式各样的改变，就像卷起风暴一般，随时袭击团队的旧习惯，然後这位乐在其中的变革者自己处在风眼当中，相对平静。

让我们互相提醒，推动任何的改革时，必须时时关切团队成员的感受，以同理心随时换位思考，别让风暴吹散了大家。同时，变革也不会是单一人的事情，每个人都可能、也鼓励成为变革者，保持开放心胸，为团队带来更多的新思维与可能性。

好了，今天先到这里，明天继续。