前言

昨天談到敏捷的重點是其背後的精神，而 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 披上一層魔法的外衣。