除非你在隱密模式下運作，否則第一個 Scrum 專案將會受到所有人的關注。選對專案和團隊至關重要——專案應該夠重要讓結果不會被忽視，但又不能大到難以駕馭。團隊成員的選擇不僅要考慮能力，更要考慮嘗試新事物的意願。

當第一個 sprint 開始時，對 Scrum 好處的期望可能會高得不切實際。你必須正確地設定和管理這些期望，否則一個本應被視為大獲成功的初始專案，反而會因為無法達到過高的期望而被認為是失敗。

Selecting a Pilot Project#

Pilot project 有兩種含義：一是作為測試來決定是否繼續；二是為後續專案引路的先行者。作者感興趣的是第二種——作為業界已有足夠證據證明 Scrum 有效，個別組織需要學習的是如何讓 Scrum 在自己的環境中運作。因此，pilot 是一種學習專案。

Four Attributes of the Ideal Pilot Project#

理想的 pilot project 位於四個因素的交匯處：專案規模、專案時程、專案重要性、以及業務贊助者的參與度。

找到「完美」的 pilot project 可能不可能，但沒關係——在四個因素之間做適當的權衡取捨，選一個夠接近的專案並開始行動，遠比等六個月以上等待完美 pilot 來得好。

Duration（時程）：

• 太短的專案會讓懷疑者說 Scrum 只適用於短期專案
• 太長的專案則要等到結束才能宣稱成功
• 最佳選擇是組織常態長度的中間值，理想約 三到四個月
• 這給了團隊足夠時間熟悉 sprint 工作方式並體驗其好處

Size（規模）：

• 選擇能以一個團隊啟動的專案，成員盡量同地工作
• 即使 pilot 會擴大，也盡量選擇不超過五個團隊的專案
• 既要在三到四個月內完成，又要協調多個團隊，會讓事情變得過於複雜

Importance（重要性）：

• 不要屈服於選擇低重要性、低風險專案的誘惑
• 不重要的專案不會得到組織的關注，團隊成員也不會全力以赴
• Jim Highsmith 建議：「不要從邊緣重要性的『學習專案』開始。要從對公司絕對關鍵的專案開始。」

Business sponsor engagement（業務贊助者參與度）：

• 採用 Scrum 需要業務端的配合，而非僅是技術端的事
• 有一位願意投入時間與團隊合作的業務端人士至關重要
• 積極的業務贊助者不僅能幫助團隊推動變革，事後推廣 Scrum 的成功也更有說服力

Choosing the Right Time to Start#

Fresh Start（全新開始）#

選擇一個新專案（或重啟一個失敗的專案）作為 pilot，讓你有一個全新的起點。團隊通常會先建立 product backlog，包含所有已知功能，然後才開始第一個 sprint。

全新開始的缺點是需要等待合適的新專案出現。記住，不要花數週或數月來建立初始 product backlog——要有紀律地以盡可能輕量的方式快速建立。

Impending Doom（迫在眉睫的危機）#

作者個人最喜歡的 pilot project 是那些正在走向失敗、但仍有時間挽救的專案。這種方法雖然有風險，但掙扎中的專案只會越來越好。由於 Scrum 聚焦於短期 sprint 內的前進進展，對這類專案特別適合。

利用「迫在眉睫的危機」很有力量，但也很危險——危險必須是真實的。重複喊狼來了會讓人不再相信。如果專案確實走向失敗但團隊不願承認，直接點出來；如果團隊對專案漠不關心，指出不改變可能面臨的後果。

Selecting a Pilot Team#

四個 pilot project 屬性和時機的交匯，遺漏了 pilot 成功最重要的因素——參與的人。在選擇 pilot 團隊時，最重要的考量是個人嘗試新事物的意願。理想情況下，所有人都已經通過 ADAPT 模型中 awareness 和 desire 階段。

作者建議組建以下類型人員的組合：

• Scrum lobbyists（Scrum 倡導者）：一直在推動採用 Scrum 的人，盡量多納入
• Willing optimists（樂觀的支持者）：認同需要新方法，聽說 Scrum 後覺得有前景並想看到成功
• Fair skeptics（公正的懷疑者）：不要排除所有懷疑者——納入受人尊敬、有過往改變意見紀錄的懷疑者，他們一旦被說服，會成為最強力的支持者

精心挑選團隊確實是在「疊牌」使之對你有利。但 pilot 不是臨床試驗——我們知道 Scrum 有效，我們不知道的是「Scrum 在這裡如何運作最好」。所以我們理所當然地疊牌，然後看看能學到什麼。

What if a Pilot Isn’t a Success?#

• 不要把所有希望押在一個 pilot 上——考慮同時進行多個 pilot
• Pilot 的目的是照亮後續 Scrum 專案的道路，最成功的 pilot 能產生「這樣做」和「不要那樣做」兩種建議
• 只要團隊從中學到了什麼可能成功、哪些方面的 Scrum 容易被引入、組織特有的阻力來源在哪裡，就不算失敗
• 不要讓 Scrum pilot 被拿來與理想化的瀑布式專案計畫做不公平的比較

Setting and Managing Expectations#

設定和管理期望是轉型初期最重要的工作之一。作者建議在四個方面設定和管理期望：進度、可預測性、態度、以及參與度。

Expectations About Progress（關於進度的期望）#

• 外部利害關係人最常聽到的 Scrum 好處是「團隊會更快」，但這不完全正確
• 一個已運作良好的團隊在採用 Scrum 初期可能會暫時放慢
• 但幾乎所有團隊都會更快地產出更有用的工作，因為 sprint 聚焦於「接下來幾週能做什麼」而非追求「最好的」或「完整的」解決方案
• 大多數團隊會高估第一個 sprint 能完成的量——例如承諾 850 小時的計畫工作，但因中斷、計畫外工作等因素只完成 725 小時

Expectations About Predictability（關於可預測性的期望）#

• Scrum 團隊使用 velocity 來衡量進度，但在最初幾個 sprint 中 velocity 會特別不穩定
• 應向利害關係人溝通，早期基於 velocity 的預測需要保留較大的誤差範圍
• velocity 通常在第三或第四個 sprint 後穩定下來
• 有大量遲交罰款的高風險合約不適合作為 Scrum pilot

Expectations About Attitudes Toward Scrum（關於對 Scrum 態度的期望）#

• Yahoo! 的調查顯示 85% 的開發者在有選擇的情況下會繼續使用 Scrum
• 但初期不會是這樣——要準備好面對大量反對和抱怨
• 常見的抱怨包括：daily scrum 浪費時間、每個 sprint 結尾的測試浪費時間、主管無法評估個人績效等
• 最好的對策是提前討論：當團隊成員事先同意在遇到困難時仍會堅持 Scrum，就較不容易退回舊習

Expectations About Involvement（關於參與度的期望）#

• 許多利害關係人習慣傳統開發模式中「把需求丟過牆再回來拿成品」的角色
• 必須讓 product owner 和其他利害關係人理解，建構軟體密集型產品不是這樣運作的
• 確保每位利害關係人知道團隊期望他們的參與程度和承諾

Scrum 不是銀彈。你應該從一開始就確保期望不會上升到不切實際的水平。管理期望可能是你在初期能做的最重要的事。如果不這樣做，你就冒著讓一個本應成功的 Scrum 轉型被視為失敗的風險。

It’s Just a Pilot#

Yahoo! 的 Pete Deemer 在啟動 Scrum pilot 計畫時，刻意將每個專案都稱為 pilot。他認為 pilot 是一個實驗，目的是獲取幫助後續專案成功的知識。「pilot」這個標籤為流程的執行創造了一層安全網——當困難出現時，人們更願意捲起袖子尋找解決方案，而不是放棄。

在轉型一年後，即使已有超過一百個 Scrum 團隊，Deemer 仍然稱每個專案為 pilot。他表示會一直這樣稱呼，直到 Yahoo! 的每個專案都採用 Scrum 並且知道了所有需要知道的事情。

無論你是否把每個專案都視為永久的 pilot，最初幾個 sprint 都至關重要。你可以透過精心挑選正確的第一個專案和團隊成員、以及準確地設定和管理期望，來確保團隊走上正確的道路。