歷史上，組織需要變革時會啟動一個有明確起點和終點的「變革計畫」，由上而下強制推行。但在變革頻率日益加快的今天，這種模式已經不再適用。作者主張，採用 Scrum 的最佳方式就是使用 Scrum 本身——以迭代的方式、在持續的基礎上進行小幅改變，這正是一種合乎邏輯的方式來採用一個本身就是迭代式的開發流程。

Shamrock Foods 的例子說明了 Scrum 的廣泛適用性：CEO Kent McClelland 將公司沿用 20 年的傳統策略規劃流程，改為以 Scrum 為基礎的迭代式策略規劃，45 位管理者和員工參與季度性的策略 sprint。

The Improvement Backlog#

就像 Scrum 開發專案使用 product backlog，組織也應該使用 improvement backlog（改善待辦清單）來追蹤導入 Scrum 的工作。Improvement backlog 列出組織在使用 Scrum 方面可以改善的所有事項。

IBM 開始採用 Scrum 時，其 improvement backlog 包含以下項目：

• 增加使用 Scrum 的團隊數量
• 增加測試自動化的採用
• 讓團隊實施持續整合
• 確保每個團隊都有 product owner
• 決定如何衡量採用 Scrum 的影響
• 增加單元測試和 TDD 的使用

Improvement backlog 是動態的，項目會隨時新增、完成或被發現不必要而移除。在小型部門或單一專案轉型中，可能只需要一個 improvement backlog；但在大型組織中，則會有多個 improvement backlog，加上一個由指導組織整體轉型的群體維護的 master improvement backlog。

The Enterprise Transition Community#

Enterprise Transition Community（ETC） 是一個啟動、鼓勵並支持組織導入 Scrum 的小型群體。ETC 的目的是創造一個文化和環境，讓對組織成功充滿熱情的人能夠釋放變革能量，讓成功帶來更多人的更多熱情。

組成#

• 成員通常不超過 12 人
• 由轉型層級中最資深的人組成
• 若是全公司採用，應包含工程、產品管理、行銷、銷售、營運、人力資源等部門的副總裁
• 若是部門級採用，可包含 QA、開發、架構、互動設計、資料庫等負責人

ETC Sprints#

ETC 以 sprint 方式推進工作，每個 sprint 以 planning meeting 開始、以 review 和 retrospective 結束。作者建議 兩週的 sprint 長度 效果最佳。IBM 的 Elizabeth Woodward 也證實兩週 sprint 最能展示動能和可見的進展。

部分 ETC 會進行 daily scrum，但這不是必須的。ETC 成員的工作不像開發團隊那樣緊密交織，且大多數成員都有繁忙的本職工作，留在原崗位反而能移除更多組織層面的障礙。

The Sponsor and Product Owner#

大多數成功的 Scrum 導入都有一個可識別的 sponsor（贊助者），即組織中對轉型成功負責的資深人士。Sponsor 同時也是 ETC 的 product owner。

• Salesforce.com 的大規模轉型由共同創辦人暨執行副總裁 Parker Harris 贊助
• Sponsor 應來自與轉型規劃相同層級的組織
• Sponsor 必須透過參與 ETC 來展現承諾，而非僅宣布支持後就抽身

僅靠支票簿式的承諾是不夠的。Jean Tabaka 認為這是 Scrum 導入失敗最可能的原因之一：「敏捷導入需要一個充滿熱情、願意做出艱難組織變革的贊助者。」

ETC 的職責#

ETC 是一個 工作群體，不是指導委員會。其核心職責：

• 闡述脈絡（Articulate the context）：幫助員工理解變革的必要性——為什麼？為什麼是現在？為什麼是 Scrum？
• 激發對話（Stimulate conversation）：辯論技術實踐的優劣、分享成功故事、探究失敗原因
• 提供資源（Provide resources）：確保轉型所需的時間、精力和資金到位
• 設定適當的目標（Set appropriate aspirations）：有清晰定義的轉型目標，成功機率高出十倍
• 讓每個人參與（Engage everyone）：確保轉型不會只聚焦在一個群體

額外職責包括：

• 預測並處理人員問題：提前辨識哪些群體或個人會在變革中掙扎最多
• 預測並移除障礙：不僅回應已通報的障礙，更要主動預防
• 鼓勵同時關注實踐和原則：組織不能只採用實踐而忽略原則，反之亦然

Improvement Communities#

Improvement Community（IC，改善社群） 是一群人自願聚在一起，協作改善組織使用 Scrum 的方式。IC 是一種特殊類型的 community of practice（實踐社群）。

• IC 可能因注意到 ETC improvement backlog 上的項目而成立
• 也可能因成員對某個改善機會充滿熱情而自發形成
• IBM 有五個 IC，分別聚焦於測試自動化、持續整合、TDD、product owner 角色、以及 Scrum 的一般使用

ETC 引導轉型過程，但不直接管理——其重要角色是營造一個讓 IC 能有機地形成和解散的環境。此方法可根據組織規模靈活調整：30 人的軟體開發部門可能只需要 5 人的 ETC；200 人的部門可能需要 10 人的 ETC 加上數個 IC。IBM 的某些 IC 甚至有超過 800 名成員。

Improvement Community Sprint#

IC 也以 sprint 方式運作，建議 sprint 長度為兩週。自發形成的 IC 通常自行擔任 product owner；因 ETC 目標而成立的 IC 則與 ETC 成員協作擔任 product owner。

IC 在 sprint planning 中從 ETC 的 backlog 取出項目，分解為更小的項目放入自己的 improvement backlog。例如，一個以「建立內部 ScrumMaster 培養計畫」為目標的 IC，會將此目標分解為：識別候選人、建立導師制度、開發內部課程、編列外部教練預算等具體項目。

Focus on Goals with Practical Relevance#

IC 要產生最大影響，必須聚焦在對開發團隊有即時且實際相關性的目標。最好的方式是 IC 成員與開發團隊成員並肩工作。

Google 的 Testing Grouplet 就是一個典範：「test mercenaries」（測試傭兵）是有測試熱情和專長的資深工程師，花 20% 的時間在三個月內幫助其他專案團隊添加測試和重構程式碼。這比單純宣講測試的好處要有效得多。

IC 成員的角色是諮詢而非佈道。早期採用者容易變成狂熱者，急於讓所有人立刻轉變。但他們往往忘記自己也花了時間才適應，過度推銷反而會造成更多抵抗。

Improvement Community Members#

任何對改善機會有熱情的人都應被鼓勵參與 IC。成員資格不應限於最資深的員工——廣泛參與能讓組織中的每個人感到變革是與他們一起發生，而非強加於他們身上。

參與 IC 不是全職工作，而是在日常工作之外的額外投入。IBM 要求 IC 領導者每週貢獻兩小時，但許多人因為渴望看到更快的進展而投入更多。Google 則讓每位員工將 20% 的時間用於感興趣的事務。Salesforce.com 有類似的 PTON（Paid Time On） 計畫，每年給每位員工一週的帶薪時間追求自選專案。

衡量有效性的兩個指標#

1. 自發形成的 IC 數量（未經 ETC 直接要求）
2. 自發形成的 IC 佔總 IC 數量的百分比

如果這兩個指標持續增長，表示組織對 Scrum 和其帶來的變革有強烈的興趣。

解散社群#

大多數 IC 最終會解散。當組織在某個領域已經足夠成熟（例如自動化測試），該 IC 的成員就可以將精力投入其他 IC。ETC 則應在組織完成轉型並進入持續改善階段後解散，但對大型轉型來說這可能需要數年。

One Size Does Not Fit All#

本章描述的社群驅動方法最適合中大型部門或組織的 Scrum 轉型。對於小型團隊，可以適當縮減規模——例如 20 人的軟體部門可能只需要一個群體，同時扮演 ETC 和 IC 的角色。

Looking Forward#

在本書的前四章中，我們討論了為什麼轉型到 Scrum 很困難但值得、伴隨變革的活動和工具、導入模式的選擇、以及如何用 Scrum 流程本身來管理導入工作。貫穿始終的一個重點是：Scrum 沒有終點。它要求持續改善，而這可以透過 improvement communities 使用 Scrum 本身來管理。

下一章將討論如何挑選第一個專案、第一個團隊，以及如何開始變得敏捷。