前言

昨天谈到敏捷的重点是其背後的精神，而 Scrum 也不例外，但为什麽 Scrum 的导入还是这麽艰辛，有这麽多辛酸史呢？

Scrum 导入有障碍

上一篇文章「自然而然的敏捷导入」，那真的跑 Scrum 时还自然得起来吗？可能有人会说：「Scrum 导入明明很有障碍！」

作为预备知识，这边非常简略提一下 Scrum。

Scrum 描绘了：

• 三个角色：Developers、Product Owner、Scrum Master
• 五个事件：Sprint、Planning、Daily、Review、Retrospective
• 三个产出：Product Backlog、Sprint Backlog、Increment

这是 Scrum 的基础，也是第一眼看上去最容易捕促到的，更是许多团队跨入的一步，之所以说它易学难精，也可以从这些名词略知一二，通常只要花一些时间了解定义，跟着活动大纲执行，那就概就有几分像了，但是每个角色、每场活动是否可以发挥的活灵活现，体现出它真正的价值，那就得看功夫了。

这些活动就像是一种捷径，一种被精心设计过，认为可以取得成果的方法，团队若没有了解这些角色与活动背後的「深意」，那麽执行起来就只是在模仿，自然陷入各种困境。

什麽深意呢？就是所谓 Scrum 的 3 大支柱与 5 大价值观。

• Scrum 的 3 大支柱：「透明」、「检视」与「调适」
• Scrum 的 5 大价值观：「承诺」、「勇气」、「专注」、「开放」与「尊重」

再说回 “Scrum” 这个词，引用「Scrum 精髓」一书的说明：

Scrum 不是缩写，它借用的是敢榄球运动术语。在敢榄球运动中，这个述语指的是在意外犯规或球出界後重新开始比赛。就算你不是球迷，也该见过争球，两个队的前锋在球前面围成一圈，彼此的胳膞架在一起，低头争夺球权。

虽然这个出自橄榄球的名词常常让人第一次看到时产生疑惑，但背後暗喻的「球队(团队)」、「合作」、「创造价值」的概念仍然精妙。

那麽，导入 Scrum 会有哪些障碍？常见的可能有高层是否支持、成员是否接纳、原本组织的行事作为是什麽、团队技能(能力)高低、团队实现自我管理前有多大的距离等，这些多少都可以在书籍或各场次的演讲议程中听到分享，但我想就另一个角度谈谈，就是我们对 Scrum 认知是否有什麽误会？

Scrum 误会

这边跟大家分享我观察到 3 个的误会，它可能发生在导入前与导入中。

速度

兵贵神速，速度一直是大家在意的，也是抢攻市场的重要利器，好在「敏捷不等於快」的这个概念也已经由无数大神们多次澄清，相信这个误会不会持续太久。

「但我现在最想做的事情就是让交付变快啊！」
「导入之後没感觉变快啊！」

哎呀！这可真是道理我都懂啊！但我导 Scrum 就是要快啊！

(不知道读者有没有看过这个梗，如上 Google 即可)

嗯… 我的看法是，也许会变快，但这个快是这样来的：

1. 来自团队回应变化而来，在整个专案过程中巧妙应对、频繁调整而来。
2. 来自团队有良好的互动与沟通，作为技能精进的後盾。
3. 来自团队有效率的协作，并减少浪费。
4. 来自团队高度自主与同心，挤心打拼，避免无谓纷争。
5. 来自利害关系人的开诚布公，让大家走在对的道路上。

而这些都是间接的，还得是团队内外都要养成这些基本能力，才能慢慢展现出来。

但是有什麽东西可以让我们慢下来？可多了！而且即时又直接，一踩到就慢，随意列举几个：

1. 领城知识不足
2. 技能不足
3. 技术债
4. 需求变更
5. 需求传达或理解有误
6. 多头马车
7. 外务插断
8. 基础设施异常，如网路、开发环境、CI/CD Runner 等

与其对於 Scrum 抱有高度期望，不如先看看目前「慢」在哪里？而这些问题，在我们决定执行 Scrum 前又存在了多久呢？又打算如何解决呢？

只剩下 Scrum

过度强化导入 Scrum 这件事之後，一时之间团队心中只剩下 Scrum 了，忘了 Scrum 本身是留下一些空白的。团队还是有许多 Scrum Guide 之外需要努力的事情，这也呼应前一小节谈「速度」时，我提到的那些造成团队交付缓慢的原因，团队本身对於工程方面的着墨有多少呢？

以软件团队为例

1. 是否有能力写出足够有弹性的程序架构，好来回应变化呢？
2. 是否有足够的自动化测试，好随时把守品质呢？
3. 是否有 Pair 或 Mob 的经验或打算，好让实作、学习，甚至品质能够继续提升？

不明究理的「守」

源自日本武术的「守破离」概念，读者可能在谈论敏捷的书籍看见过。它描述学习的过程中从按部就班的「守」，到了融合各方与自己见解的「破」，最终产出自己的一套方法「离」。把这个观念放到 Scrum 来，可以知道一开始的「守」是要我们循规蹈矩，熟练每个基本功。

如果成员只把 Scrum 相关活动看成一种规范、一种要遵守的制度、一种上司/公司的要求，而无法内化它，就很难在工作上展现其精神，这样的导入即便流程再怎麽完美，也总有不到位的地方。

以下列举了一些问题，我们可以试着回答，看看我们对正在「守」的事物有怎样的认知：

1. 为什麽要开 Daily Scrum？为什麽要限 15 分钟以内？
2. 为什麽要更新看板，我只要最後交得出来不就行了？
3. 为什麽要用使用者故事 (User story) 来表达？
4. 为什麽规划会议要全团队参加，这不是很浪费时间吗？
5. 为什麽要使用 Planning Poker (或 T-Shirt Size) 估计？
6. 为什麽不要直接估计工时？
7. 为什麽要团队来想，这不是 PM 的工作吗？
8. 为什麽要自己认领工作，这不是主管该指派的吗？
9. 为什麽要开回顾会议，把时间拿来 Coding 不是比较好吗？

小结

在细部谈论 Scrum 活动前，不难发现已有各种误会存在，若团队或利害关系人没有厘清，还是会走不少歪路。

Scrum 是个值得尝试的框架，我们期待它可以为团队来带正向的循环，而不要让已存在的问题成为否定它的原因。

回应标题「Scrum 也自然吗？」，我认为是的，只是我们常常会不小心想太多，产生过多的幻想，让 Scrum 披上一层魔法的外衣。