Lori Schubring 是一家大型製造公司的應用開發經理。她意識到公司的開發流程已經過度形式化，阻礙了業務的靈活性。她的經歷完美體現了成功且持久地採用 Scrum 所需的五個核心活動：

• Awareness（覺察）：意識到當前流程無法交付令人滿意的結果
• Desire（渴望）：希望採用 Scrum 來解決當前問題
• Ability（能力）：具備成功實施 Scrum 的能力
• Promotion（推廣）：透過分享經驗讓我們和他人看到成功
• Transfer（轉移）：將使用 Scrum 的影響擴展到全公司

這五個活動的首字母組成 ADAPT 這個縮寫，源自 ADKAR 變革管理模型，但針對軟體開發進行了調整。

如 Figure 2.1 所示，Awareness、Desire 和 Ability 三者相互重疊，而 Promotion 和 Transfer 則在整個轉型過程中反覆進行。轉型完成後，這個循環會持續下去，推動持續改善。

成功採用 Scrum 的組織會在多個層級同時進行這些活動：

• 組織層級：整個組織需要達到一定的臨界量才能集體前進
• 個人層級：每個人會以不同的速度經歷轉型過程
• 團隊層級：團隊成員傾向於一起經歷 ADAPT 循環
• 實踐層級：每一個新技能（如自動化測試）的採用都會經歷自己的 ADAPT 循環

Awareness（覺察）#

變革始於覺察到現狀已不再令人滿意。然而，意識到過去有效的方法已經不再適用，可能是極其困難的。

作者分享了一個親身經歷：1990 年代中期他擔任一家醫療軟體公司的開發總監，公司創辦人在全體會議上展示了「Valley of Death」（死亡之谷）圖表——現有產品的營收將在新產品的營收增長之前急劇下降。

很少有人能像這位創辦人一樣有先見之明。變革的需求出現和我們意識到之間，幾乎總是存在時間差。以下是人們遲遲無法覺察的常見原因：

• 缺乏全局視野：變革的需要可能只有看到銷售下滑、聽到競爭對手動態的人才能感受到
• 拒絕面對現實：即使需要改變的跡象很明顯，我們有時仍會否認，認為問題是暫時的
• 把動作誤當進展：每天都有會議、報告、程式碼被簽入，很容易把這些繁忙的活動誤認為真正的進展
• 聽信自己的宣傳：公司內部的自我慶祝文化容易造成自滿

培養覺察的工具#

• 溝通問題的存在：BioWare（知名遊戲開發商）儘管有成功的產品，專案仍然受到加班、溝通問題等困擾。他們設定了一個令人難以反駁的目標：「以開發時的樂趣媲美遊戲本身的樂趣，以更低的成本交付高品質的遊戲。」這個目標高明之處在於它既不說教也不指定解決方案

William Bridges 在 Managing Transitions 中強調：重要的是「推銷問題，而非特定的解決方案」。

• 使用指標：員工離職率、工作滿意度調查結果、每位員工的營收等簡單指標，都能有力地傳達變革的必要性
• 接觸新的人和經驗：鼓勵人們參加研討會、拜訪客戶、了解競爭對手的產品。長期策略是在招募時重視多元化背景
• 執行試點專案：成功的試點專案最有說服力。面對成功，那些尚未覺察到變革需要的人要嘛必須折服，要嘛承認改變是可能的
• 聚焦最重要的變革原因：不要列出一長串問題清單，而是找出造成最多問題的兩到三個核心原因

Desire（渴望）#

意識到需要改變是不夠的——還必須有改變的渴望。正如作者所說：「我知道我應該多吃蔬菜，但我還沒有渴望去改變飲食。在覺察轉化為渴望之前，我的飲食不會改變。」

從覺察到渴望的轉變可能非常困難。我們的教育和經驗讓我們偏好循序漸進的方式；我們可能對現有專案的某些元素感到不滿，但已經努力爭取到了合適的老闆和團隊，Scrum 會改變這一切。有時候，時機就是不對。

同樣的訊息在不同的時間傳達，效果可能截然不同。如果時機不對，再怎麼說服也沒用。好消息是，在適當的時間重新傳達相同的訊息，往往足以讓人從覺察轉向渴望。

激發渴望的工具#

• 溝通更好的方式：在建立覺察時，溝通聚焦於問題本身；轉向激發渴望時，溝通則聚焦於 Scrum 如何解決這些問題。但要注意不要同時傳達兩種訊息，以免人們因為資訊過載而關閉
• 創造急迫感：讓人們清楚地知道現狀不能繼續維持下去
• 建立動能：與其把精力花在說服抵抗者，不如幫助那些已經熱情的人成功。Steve Greene 和 Chris Fry（Salesforce.com）建議「專注於讓幾個團隊達到卓越」，讓 Scrum 的採用看起來勢不可擋
• 讓團隊試駕 Scrum：與其抽象地討論 Scrum，不如讓團隊嘗試三個月。這段時間足夠度過最初的不適期，之後再由整個團隊集體決定如何前進
• 調整激勵機制（至少移除反向激勵）：許多獎勵計劃會無意中對抗 Scrum 的團隊合作精神。例如只獎勵個人貢獻的獎金制度、根據發現 bug 數量獎勵測試人員的制度等，都需要調整為以團隊為導向的標準
• 化解恐懼：Product owner 可能害怕失控的開發團隊，管理層可能害怕進度延遲，架構師可能害怕失去設計權威。找到這些恐懼並解釋為何它們可能是沒有根據的
• 讓人們放手：每次轉型都伴隨著失去，失去帶來悲傷。允許人們有時間去哀悼，傾聽他們的失落感
• 不要詆毀過去：不管過去的開發流程有多少問題，它帶領組織走到了今天。詆毀過去會讓認同舊方式的人感到自我價值受到攻擊，反而鞏固他們的抵抗
• 讓員工參與：爭取盡可能多的盟友，尤其是受到廣泛尊重的意見領袖。他們的感染力能迅速擴散到整個組織
• 讓懷疑者也參與：詢問員工需要看到什麼、經歷什麼、知道什麼才願意嘗試 Scrum，然後想辦法給他們

Ability（能力）#

再多的覺察和渴望，如果團隊沒有實踐 Scrum 的能力，也不會有任何進展。Scrum 不僅要求學習新技能，還要求忘卻舊技能。團隊面臨的主要挑戰包括：

• 學習新的技術技能：開發者需要學習演進式設計（evolve design）、測試人員需要學習在較少文件下進行測試、兩者都需要學習自動化測試
• 學習團隊協作的思維：從「你做你的部分，我做我的部分」轉變為共同承擔責任
• 學習在短時間框架內交付可用軟體：Scrum 的短迭代（sprint）對習慣長開發週期的團隊是重大挑戰，需要消除不必要的交接、更緊密地合作

培養能力的工具#

• 提供教練和培訓：Scrum 與傳統軟體開發差異很大，通常需要培訓配合現場教練或導師。Lori Schubring 說：「我們能成功使用敏捷，始於教育過程。如果我們不理解某件事，就不可能張開雙臂歡迎它。」先進行概念性的 Scrum 培訓，再跟進特定實踐（如 TDD）的實作培訓

Salesforce.com 的 Chris Fry 和 Steve Greene 事後回顧，希望「更早培訓 product owner，且培訓更密集」，並且「更早獲得外部教練的幫助」。他們對轉型中的公司的建議是：「尋求專業幫助。」

• 讓個人負起責任：在提供教練和培訓的同時，員工需要知道他們將被要求運用組織花錢讓他們學習的新技能
• 分享資訊：團隊成員在學習過程中會面臨大量新資訊和挑戰。鼓勵跨團隊交流——參加其他團隊的 daily scrum 或 sprint review，使用內部網路、Wiki、實踐社群（communities of practice）和讀書會來傳播資訊。Yahoo! 甚至在加州總部舉辦了全天的內部 open space 研討會
• 設定合理的目標：不要一次要求太多。與其要求團隊「開始做 TDD」，不如要求他們在下一個 sprint 中用 TDD 開發一個功能。將大目標拆成小的、可行動的步驟
• Just do it：不要拖延，等待所有答案才開始。正如 Greene 和 Fry 所建議的：「實驗、保持耐心、並預期會犯錯。」

Promotion（推廣）#

推廣有三個目標：

1. 為下一輪 ADAPT 循環奠定基礎：推廣當前的成功，為下一輪改善提前建立覺察
2. 強化現有團隊的敏捷行為：傳播好消息，鼓勵已採用 Scrum 的團隊持續進步
3. 在開發團隊以外創造覺察和興趣：讓人資、業務、行銷等部門了解 Scrum 的影響

避免將轉型變成行銷活動。歷經無數「Quality 2000」、「Better, Faster, Cheaper」等口號的員工，對又一個包裝精美的變革計劃只會報以冷嘲熱諷。Glenn Allen-Meyer 建議讓變革過程保持無名，因為命名會讓人覺得被強迫「要嘛承諾、要嘛服從、要嘛離開」。

Thomas 的故事很有啟發性：他第一次嘗試 Scrum 失敗後，18 個月後再次嘗試時，刻意避免使用 Scrum 的專有詞彙（ScrumMaster、sprint、product backlog 等），而是告訴老闆他們要「做 agile」（用小寫的 a）。這次成功了。

推廣 Scrum 的工具#

• 公開成功故事：透過內部經驗報告、簡報等方式傳播早期採用者的成功。早期的指標可以很簡單——享受使用 Scrum 的人數比例、認為生產力提高的比例等
• 口碑傳播：BioWare 的 ScrumMaster Benoit Houle 說：「就像病毒行銷一樣，最好的媒介是口碑。團隊成員讚揚這個流程帶來更多的團隊擁有感、更好的可預測性、更少的浪費和加班。其他人聽到了，也想要加入。」
• 舉辦 Agile Safari：Google 的做法——讓好奇但尚未有機會參與敏捷的人加入一個敏捷團隊幾週，親身體驗
• 吸引注意力：Lori Schubring 在萬聖節舉辦了「Open House」活動，邀請業務部門來參觀開發團隊使用 Scrum 的情況，準備了 Scrum 主題的填字遊戲和獎品
• 利用資訊輻射器：在走廊放置布告欄，展示 4"x6" 的卡片、團隊組成照片、burndown chart 等，讓路過的人都能看到團隊的進展

Transfer（轉移）#

Gino 的故事是一個警示。他花了三年時間推動公司的 Scrum 轉型，讓超過 500 位開發者使用 Scrum，甚至晉升為「Scrum Office」的負責人。但在他離開公司後，Scrum 的採用最終失敗了——因為沒有人將 Scrum 的影響轉移到開發組織以外。同樣的個人獎金制度、業務人員仍然可以繞過團隊直接向客戶承諾功能。

作者將 Scrum 比喻為一枚火箭。推動火箭前進的是引擎的動力，但將它拉回的是組織慣性（organizational gravity）。如果火箭無法推得夠遠進入軌道，它終將被拉回地面。Scrum 的影響必須被推展到組織的其他部分，轉型才不會被組織慣性拉回原點。

組織慣性的來源#

需要將 Scrum 的影響轉移到以下群體（注意：測試和產品管理不在此列，因為他們是 Scrum 的基本參與者，從一開始就需要融入）：

• 人力資源：許多 HR 政策與 Scrum 的成功採用相衝突。強制排名員工的績效考核制度會破壞團隊合作；獎勵個人貢獻而忽視團隊合作的評估標準同樣有害。需要調整為包含「幫助他人進步」、「分享知識」、「願意跨越職位範圍工作」等團隊導向的標準
• 設施管理：許多團隊被告知不能在牆上掛索引卡、burndown chart 等。需要與設施部門溝通，爭取支持敏捷團隊空間的配置。BioWare 的經驗是設施部門重新設計了樓層，建造了支援 6-8 人團隊的大房間
• 行銷：需要讓行銷部門了解 Scrum 提供的透明度。Scrum 團隊漸進式細化計劃且嚴格遵守日期的特性，對行銷部門其實是有利的
• 財務：與財務部門的交集主要在兩個方面——專案進度和預算的預測，以及工時追蹤與專案資本化。需要讓財務部門理解 Scrum 無法從一張餐巾紙上的產品描述做出 5% 誤差以內的預算估算，但可以提供早期的進度預警

總結#

ADAPT 是一個迭代的過程。它始於組織中的一些人覺察到現有的工作方式不再令人滿意。隨著覺察的擴散，一些人產生了嘗試 Scrum 的渴望。透過反覆試錯，這些早期採用者發展出成功使用 Scrum 的能力。一個新的現狀可能出現：在一個更大的非敏捷組織中，少數團隊成功地使用 Scrum。

當這些初始團隊持續改善，他們開始推廣自己的成功——有時是在與朋友的午餐中非正式地分享，有時是在部門級的正式簡報中。這幫助其他團隊的個人從覺察進展到渴望再到能力。

但如果整個過程被視為僅發生在開發組織內部，那麼長期成功就會受到威脅。必須將使用 Scrum 的影響轉移到受影響的其他部門——業務、行銷、營運、人力資源和設施管理等。這些群體不需要使用 Scrum，但需要在與開發團隊的互動方式上做出調整，否則組織慣性最終會拖累甚至扼殺轉型努力。