組織採用 Scrum 的路徑各有不同，但從已成功轉型的公司中，可以歸納出一些常見的模式。本章探討四種模式，它們對應兩個在任何 Scrum 導入初期都必須回答的關鍵問題：

• 應該從一兩個團隊開始，還是一次全面轉換？
• 應該公開宣布轉型意圖，還是低調進行？

此外，本章也探討了三種在初始團隊之後擴散 Scrum 的選項，以及新團隊何時應開始採用敏捷技術實踐。

Start Small or Go All In#

Start Small 模式#

傳統且被廣泛推薦的做法是 start-small 模式：從一到三個團隊（每組五到九人）開始試行，取得成功後再向外擴展。隨著 Scrum 在組織中擴散，新團隊可從先行者的經驗中受益。Start small 有許多變化，取決於組織希望轉型的人數和速度。

All-In 模式#

All-in 模式則是一次將所有團隊轉換到 Scrum。Salesforce.com 就是典型案例——2006 年一夜之間將 35 個團隊全部轉為 Scrum。這種做法適合積極進取、成就導向的文化，因為他們認為如果 Scrum 值得一個團隊使用，就值得所有團隊使用。

兩種模式也可以結合：先進行一到三個團隊的 pilot，隨即全面推行。Pilot 的目的不僅是學習，更是提高組織對 Scrum 的認知。

偏好 Start Small 的理由#

• 成本較低：All-in 需要更多外部教練和 ScrumMaster，而 start small 可先培養內部專業能力
• 幾乎保證能早期成功：透過精心挑選初始專案和團隊成員，可以大幅提升成功機率
• 避免 all-in 的重大風險：如果全面轉型中犯了錯並倒退回舊流程，團隊成員不太可能給予第二次機會
• 壓力較小：早期採用者會成為教練和大使，以自身經驗鼓勵其他團隊
• 無需立即重組：全面採用 Scrum 最終會需要某種程度的組織重組，start small 可以推遲這個需求

偏好 All-In 的理由#

• 可減少阻力：全面投入展現了對新流程的承諾，讓懷疑論者無法寄望轉型會被放棄
• 避免 Scrum 與傳統團隊並存的問題：部分轉型會造成 Scrum 團隊與傳統團隊在規劃、溝通上的摩擦
• 轉型更快完成：組織可以更快到達「最困難的部分已經過去」的時間點

如何選擇#

• 當領導層不願全面承諾、失敗代價高昂，或組織緊迫需要 Scrum 好處時，選擇 start small
• 當時間緊迫、需要向批評者傳達明確訊息時，考慮 all-in
• 絕不要在沒有足夠 ScrumMaster 的情況下 all-in
• 組織規模也很重要：10 人可以直接 all-in，超過 400 人則可能在後勤上不可行

Public Display of Agility or Stealth#

Public Display of Agility#

公開展示敏捷（public display of agility）是指團隊或組織公開宣布正在採用 Scrum，範圍從午餐時的閒聊到全國性的新聞稿都有可能。

Stealth Transition#

隱密轉型（stealth transition）則是只有團隊成員知道自己在使用 Scrum，直到專案完成才對外公開。隱密程度不一——有些團隊主動保密，有些只是不特別宣傳。

偏好公開展示的理由#

• 公開承諾讓你更可能堅持下去：就像公開宣布你在節食一樣，朋友的支持和無形壓力有助於堅持
• 建立共同願景：公開意圖能創造討論空間，團隊成員能自在地分享成敗
• 展現堅定承諾：隱密轉型可能被視為缺乏信心，公開則傳達「我們不只計畫啟動，還計畫成功」
• 可以尋求組織支援：轉型中會遇到許多障礙，保密會限制尋求外部協助的能力
• 先宣告目標再達成，發出強力訊息：事前告知比事後透露更有說服力

偏好隱密轉型的理由#

• 在阻力出現前先取得進展：公開宣布會讓抵抗者浮出水面，而在變革獲得動能之前對抗最有效
• 減少額外壓力：高調宣傳會讓團隊同時承受專案和轉型的雙重壓力
• 失敗無人知曉：可以悄悄調整做法，等到成功後再公開
• 無人能阻止你：如果只有參與者知道，就不會有人命令你停止

如何選擇#

• 當對 Scrum 有信心且已做好承諾，或預期會有強烈阻力但想快速克服時，選擇公開展示
• 當想先實驗 Scrum 的部分做法、缺乏政治影響力、或公開會造成過大阻力時，選擇隱密轉型
• 作者觀察：願意公開展示的組織，比採用隱密方式的組織更容易成功轉型

Patterns for Spreading Scrum#

除非選擇 all-in 轉型，否則需要將初始團隊的成功經驗擴展到其他團隊。有三種主要的擴散模式。

Split and Seed（拆分播種）#

在 split-and-seed 模式中，一個運作中的 Scrum 團隊被一分為二，各半組成新團隊的基礎，再加入新成員組成完整的 Scrum 團隊。

新成員可以是新進員工或首次加入 Scrum 專案的既有員工。第二代團隊因為有經驗成員的指導，學習 Scrum 會更容易。新團隊磨合幾個 sprint 後，再次拆分，如此循環直到全面導入。

Grow and Split（成長拆分）#

Grow-and-split 是 split-and-seed 的變體：持續為現有團隊加入新成員，直到團隊大到可以舒適地拆分為二。

拆分後每個新團隊會在理想規模（五到九人）的較小端。經過一個 sprint 的穩定期後，再加入新成員，重複此模式直到全組織轉型。

Internal Coaching（內部教練）#

第三種模式是 internal coaching。Philips Research 的做法是：在每個表現優秀的團隊中找出一位真正理解敏捷的人，指派為另一個較落後團隊的教練。教練的職責包括參加 sprint planning、review、retrospective 會議，每週參加一次 daily scrum，並每週提供兩小時的額外協助。

各模式的偏好理由#

Split and Seed 的優勢：

• 擴展速度最快——2-3 個 sprint 後即可拆分，5-6 個 sprint 後可擁有超過 100 位有 Scrum 經驗的人
• 每個新團隊都有具經驗的成員引導

Grow and Split 的優勢：

• 不需要拆散剛成形的團隊
• 團隊成員在 sprint 之間感受到更多連續性，較少被打斷的感覺

Internal Coaching 的優勢：

• 運作良好的團隊不需要被拆分
• 可以為每個新團隊手動挑選最合適的教練
• 教練可以在團隊之間流動，像蜜蜂一樣傳播新想法

選擇你的方法#

• 趕時間時考慮 split and seed——這是最快的擴散方式
• 不那麼緊迫或團隊本身在成長時考慮 grow and split
• 組織夠大以至於好的實踐無法自然擴散、或拆分團隊不實際時，考慮 internal coaching
• 三種模式可以組合使用——例如先用 split and seed，隨著團隊數量增加改用 grow and split，同時輔以 internal coaching

使用 split and seed 時要注意：如果技術和領域知識不支持跨團隊移動人員（例如將 Java 程式設計師放入 .NET 團隊），就不適合這種做法。

Introducing New Technical Practices#

新 Scrum 團隊應該多快開始採用新的技術實踐（如簡單設計、自動化測試、結對程式設計、重構等）？有兩派觀點。

及早開始的理由#

• 可以快速獲得改善：結對程式設計可以幫助程式設計師跨領域學習，持續整合可以減少整合問題
• 不及早嘗試可能永遠不會嘗試：許多 Scrum 團隊只採用最低限度的 Scrum 就停下來，錯失了大量可能的改善
• 可能正好解決專案最迫切的問題：如果專案的主要問題（品質差、過度設計、交付週期長）可以透過技術實踐來解決，就應該儘早引入

延遲的理由#

• 某些實踐可能遭遇強烈抵抗：簡單設計、結對程式設計、TDD 等對許多人來說很難接受，在轉型初期強推可能適得其反
• 團隊成員可能已經忙不過來：光是學習 Scrum 的基本運作方式就很有挑戰性，額外的技術實踐可能讓團隊超載

給予足夠時間，Scrum 嚴格的 timebox 壓力本身就會促使團隊認識到需要嘗試新的技術實踐。

One Final Consideration#

本章提出的兩個問題——start small 還是 all-in？公開還是隱密？——答案不必是二元的。在 start small 和 all-in 之間有很大的中間地帶，擴散模式也可以根據情況組合使用。

無論選擇哪種模式，轉型領導者都必須注意一次要改變多少。改變太多會讓團隊迷失方向；改變太少則會讓人在漫長的小變化中疲憊不堪。

採用 Scrum 這樣的敏捷方法是一個持續改善的過程，沒有預定的終點。正如 Kent Beck 所說：「一次改變一件事很容易上手。XP 在所有東西一起運作時效果最好，但你需要一個起點。」