許多軟體開發組織都在努力變得更加敏捷。成功的敏捷團隊能以更低的成本、更快的速度交付更高品質的軟體。但在這些光鮮亮麗的數字背後，轉型到 Scrum 的過程遠比多數公司預期的困難。改變實踐方法是一回事，改變心態則是另一回事。

作者分享了幾個失敗案例：一家公司花了超過一百萬美元推動轉型，卻因為只關注開發部門而忽略了業務、行銷和財務部門的配合，最終被組織慣性拉回原點；Josef 在小專案上成功導入 Scrum，卻在擴展時遭到中階管理者的抵制；Caroline 的公司在初期取得進展後，因為忘記持續改善而停滯不前。

這些失敗都出於善意。轉型到 Scrum 雖然困難，但只要方法正確，完全是可行的。

為什麼轉型如此困難#

所有變革都是困難的，但轉型到 Scrum 有幾個特殊屬性，使它比大多數其他變革更加棘手：

• 成功的變革既非純粹由上而下，也非純粹由下而上
• 最終狀態不可預測
• Scrum 的影響無所不在
• Scrum 與傳統做法截然不同
• 變革的速度前所未有
• 最佳實踐是危險的

成功的變革不能只靠上層或基層#

成功的組織變革必須同時具備 top-down 和 bottom-up 的元素。純粹由上而下的變革，缺少基層的參與，個人會抗拒被告知該做什麼；純粹由下而上的變革，當 Scrum 流程開始影響原有團隊以外的領域時，會遭遇無法克服的阻力——中階管理者會為了保護自己的部門而反擊。

Mary Lynn Manns 和 Linda Rising 在 Fearless Change 一書中指出：「變革最好從基層引入，並在適當時機獲得管理層的支持。」

最終狀態不可預測#

沒有任何一個流程框架（無論是 XP、Scrum 或其他）能完美適用於你的組織。你必須根據自身獨特的環境來量身打造。Alistair Cockburn 指出，讓團隊有機會改變或客製化流程，是成功採用的關鍵因素。

由於 Scrum 本身強調持續改善，因此不存在所謂的最終狀態。傳統的差距分析（gap analysis）方法在這裡行不通，因為我們既無法預知終點，也無法預測達到中間狀態的確切路徑。最好的策略是採用「provoke and observe」（刺激並觀察）的方式——嘗試一些改變，觀察是否朝改善的方向前進，然後繼續迭代。

Scrum 的影響無所不在#

Scrum 對開發人員的影響是全面性的：必須在短時間框架內完成小塊工作、撰寫自動化測試、進行結對程式設計等。這些不是每天花幾小時就能應付的局部改變，而是徹底改變工作方式的根本性變革，因此抵抗也更強。

此外，Scrum 的影響遠超出軟體開發部門。財務需要調整資本化政策、業務需要改變溝通方式和合約結構、行銷也會受到波及。受影響的群體越多，產生誤解和抵抗的機會就越大。

Scrum 與傳統做法截然不同#

Scrum 要求人們unlearn（忘卻）過去的訓練。測試人員必須學習不再只是對照規格書驗證，而是關注使用者需求；程式設計師必須接受在編碼前不一定需要完整設計。這些改變挑戰了人們長年建立的專業認同。

採用 emergent design（湧現式設計）對許多資深開發者來說特別痛苦。正如一位開發者所言：「那些你以為讓你成為優秀開發者的東西，現在反而被認為是壞習慣。」

變革的速度前所未有#

Alvin Toffler 在 1970 年就提出 future shock（未來衝擊）的概念——當「太多變化在太短時間內發生」，人們會感到迷失方向。許多組織的員工早已長期承受未來衝擊：外包、分散式團隊、技術平台不斷更新。在這些既有壓力之上再加入 Scrum 的全面性變革，很容易將人們推入未來衝擊的狀態。

最佳實踐是危險的#

在多數組織變革中，成功的做法會被整理為「最佳實踐」供大家遵循。但在 Scrum 中，最佳實踐會削弱持續改善的動力。豐田生產系統創始人大野耐一（Taiichi Ohno）寫道：「如果你把某個標準當作最好的，那改善的動力就消失了。」

團隊成員當然應該分享好的工作方式，但必須抗拒將其固化為一套最佳實踐的衝動。

為什麼值得付出努力#

儘管轉型困難重重，已經完成轉型的公司對結果非常滿意。Scrum 帶來的好處形成一個良性循環：高品質帶來高生產力，高生產力縮短上市時間，員工因為做有品質的工作而更滿意，更高的滿意度又帶來更高的生產力。

本章引用的資料來源包括：

• QSMA 研究：Michael Mah 將 26 個敏捷專案與 7,500 個傳統專案的基準資料庫進行比較
• David Rico 研究：彙整 51 份已發表的敏捷專案研究
• VersionOne 和 DDJ 問卷調查：分別對超過 3,000 人和 642 人的產業調查

更高的生產力與更低的成本#

QSMA 的研究發現，敏捷專案的生產力比傳統專案高出 16%，且這個差異具統計顯著性。

DDJ 調查中，82% 的受訪者認為使用敏捷方法後生產力有所提高；VersionOne 調查中，73% 的受訪者認為生產力顯著改善（23%）或有所改善（50%）。

David Rico 的研究顯示，敏捷專案的生產力中位數提升為 88%，成本中位數節省為 26%。

敏捷團隊還有一個重要但難以量化的優勢：他們更不容易開發不再被需要的功能。由於頻繁的回饋和重新排序優先級，Scrum 團隊更可能只專注於使用者真正需要的功能。

改善員工投入度與工作滿意度#

Salesforce.com 在採用 Scrum 15 個月後調查員工，發現 86% 的人認為工作是一段美好時光，而在採用 Scrum 之前這個數字只有 40%。VersionOne 調查中 74% 的受訪者表示團隊士氣有所改善。

加班時間也大幅減少。一項研究發現，實施敏捷前團隊平均加班率為 19%，導入敏捷後降至 7%，減少了近三分之二。工作節奏的可持續性是員工滿意度提升的重要因素。

更快的上市時間#

QSMA 研究發現，敏捷專案的上市時間比傳統專案快 37%。VersionOne 調查中 64% 的受訪者表示上市時間有所改善。

敏捷團隊上市速度更快有兩個原因：第一，更高的生產力讓功能開發更快；第二，敏捷團隊更傾向於增量式發布——當利害關係人意識到每個 sprint 都能產出有價值的功能時，他們往往不再需要等待所有功能一次交付。

Salesforce.com 在轉型到 Scrum 後立即感受到了好處。第一年就發布了多出 94% 的功能，每位開發者交付多出 38% 的功能，向客戶交付的價值增加超過 500%。

更高的品質#

Scrum 團隊生產力更高的一個重要原因是他們持續產出高品質的工作。沒有遺留的 bug 拖累團隊，才能快速且穩定地前進。品質的提升來自於可持續的工作節奏、結對程式設計、重構、以及對早期和自動化測試的重視。

David Rico 的研究發現，敏捷專案的品質最低改善 10%，中位數改善 63%。VersionOne 調查中 68% 的受訪者認為品質有所改善，84% 認為缺陷減少了 10% 以上。

改善利害關係人滿意度#

DDJ 調查發現 78% 的受訪者認為使用敏捷流程後利害關係人滿意度有所提高。利害關係人更滿意的一個重要原因是，敏捷實踐更能適應當今快節奏競爭環境中不斷變化的優先順序。VersionOne 調查中 92% 的受訪者認為敏捷改善了管理變更優先順序的能力。

既有做法已經行不通了#

考慮轉型的最後一個理由是：你目前的開發流程可能已經不再有效。Yahoo! 的首席產品長 Pete Deemer 就是最早認識到變革必要性的人之一。Yahoo! 最初嘗試 Scrum 純粹是出於絕望——瀑布式方法顯然已經行不通，而企圖透過「更多的規劃、更多的文件、更多的簽核」來改善瀑布式方法，只是讓情況更糟。

展望#

成為敏捷組織是困難的，比大多數其他組織變革更難。本章列出了原因：需要同時從上而下和從下而上推動變革、無法預知最終狀態、Scrum 帶來的劇烈且全面的改變、在已有大量變化的環境中再加入更多變革、以及需要避免將 Scrum 變成一套最佳實踐清單。

但這些挑戰帶來的回報是巨大的：更高的生產力、更低的成本、更快樂的員工、更短的上市時間、更好的品質、以及更高的利害關係人滿意度。下一章將深入探討如何從「意識到需要改變」邁向真正的實踐。