轉型到 Scrum 時，一個常見的反對來源是對 Scrum 專案中新角色的困惑。ScrumMaster 和 Product Owner 這兩個角色在轉型前的組織中沒有完全對應的職位。在人們搞清楚這些角色的內涵以及誰適合擔任之前，很難安排合適的人選。

本章描述 ScrumMaster 和 Product Owner 的職責、理想候選人的特質，以及如何克服這些角色帶來的常見問題。

ScrumMaster 的角色 (The Role of the ScrumMaster)#

Servant-Leader 的矛盾#

許多新接觸 ScrumMaster 角色的人會對一個明顯的矛盾感到困惑：ScrumMaster 既是團隊的僕人式領導者 (servant-leader)，又是沒有權威的人。這個看似矛盾在我們理解以下區別後便消失了：

• ScrumMaster 對團隊成員沒有權威
• ScrumMaster 對流程有權威

ScrumMaster 可以說「我們決定在下個月嘗試兩週的 sprint」，但不能說「你被開除了」。ScrumMaster 的角色類似私人教練——幫助你遵循訓練計畫、以正確姿勢完成所有練習、在你想偷懶時提供動力，但教練的權威是有限的，是由客戶授予的。ScrumMaster 也是如此：他們有權威，但那是團隊授予的。

優秀 ScrumMaster 的六大特質#

作者從共事過的最佳 ScrumMaster 中，歸納出六項共同特質：

1. 負責任的 (Responsible)

ScrumMaster 負責最大化團隊的產出量，並協助團隊成員採用和使用 Scrum。這種責任是在不擁有任何有助於達成目標的權威的情況下承擔的。可以把 ScrumMaster 想像成交響樂團指揮——為一群有才華的個人提供即時指導和領導力，共同創造沒有人能獨自完成的作品。

2. 謙遜的 (Humble)

好的 ScrumMaster 不是為了自我。她的成就感來自「看看我幫助完成了什麼」，而非「看看我完成了什麼」。謙遜的 ScrumMaster 願意做任何必要的事來幫助團隊達成目標。

3. 協作的 (Collaborative)

ScrumMaster 確保團隊內存在協作文化。當爭議出現時，鼓勵團隊思考對所有人都有利的解決方案，而非勝負之分。好的 ScrumMaster 不僅示範協作態度，還會將協作確立為團隊規範，並在必要時指出不當行為。

4. 投入的 (Committed)

ScrumMaster 必須對專案和當前 sprint 目標感到與團隊成員同等程度的投入。好的 ScrumMaster 不會讓障礙懸而未決太多天。展現投入的一個方式是在整個專案期間擔任該角色——中途更換 ScrumMaster 對團隊是一種干擾。

5. 有影響力的 (Influential)

成功的 ScrumMaster 能影響團隊內外的人。在團隊內，可能需要說服成員嘗試新的技術實踐；在團隊外，可能需要說服傳統團隊提供支持，或讓 QA 主管分配全職測試人員。ScrumMaster 應該知道如何在不訴諸獨裁的情況下發揮影響力，理想情況下還具備一定的組織政治嗅覺。

6. 知識豐富的 (Knowledgeable)

除了對 Scrum 有扎實的理解和經驗外，最好的 ScrumMaster 還具備技術、市場或其他專業知識來幫助團隊。LaFasto 和 Larson 的研究結論是：「對事物如何運作的親密而詳細的知識，增加了領導者幫助團隊浮現更微妙的技術議題的機會。」

Tech Lead 轉任 ScrumMaster#

作者提醒不要僅僅因為技術知識而直接將 Tech Lead 指定為 ScrumMaster。主要風險包括：

• Tech Lead 習慣指揮團隊，團隊成員也習慣向 Tech Lead 尋求決策。但 ScrumMaster 不做決策。
• Tech Lead 往往缺乏擔任 ScrumMaster 所需的人際關係技能。ScrumMaster 必須是能引導和領導自組織團隊的促進者。

評估 Tech Lead 是否適合擔任 ScrumMaster 的最佳方式是看他過去如何使用領導權威。過去採取「我說了算」風格的 Tech Lead 不會是好的 ScrumMaster；而那些本可以獨裁但選擇凝聚支持者的 Tech Lead 可能會做得很好。

內部或外部 ScrumMaster#

長期而言，具備技能的 ScrumMaster 應該從組織內部培養。但學習如何在沒有權威的情況下領導、何時引導團隊採用新的工程實踐等，都很難在沒有親眼見過的情況下學會。因此，許多組織在初期會引入外部顧問擔任 ScrumMaster，同時作為導師來培養組織內的未來 ScrumMaster。

輪替 ScrumMaster#

作者不建議常態性輪替 ScrumMaster 角色，因為這對角色的挑戰和重要性缺乏適當的尊重。輪替的問題包括：

• 輪替的人通常還有其他 sprint 任務，且這些任務常被優先處理
• 很難訓練足夠多的人把角色做好
• 有人會利用 ScrumMaster 的身份推動自己想要的流程改變
• 只當一兩個 sprint 的 ScrumMaster 不會自動讓人重視這份工作

但在某些特定情境下可以暫時輪替，例如讓團隊成員理解 ScrumMaster 的職責，或在多位優秀候選人中選出最合適的人。

克服常見問題#

不適合的人擔任了角色：如果你對 ScrumMaster 有權威，與志願者見面，解釋為什麼需要不同的人選。如果沒有權威，從團隊最大利益的角度與該人對話，強調其優勢，建議他可能有更好的方式在專案中發揮才能。

ScrumMaster 同時也是團隊的程式設計師/測試員：當無法配備專職 ScrumMaster 時，需要在讓一位 ScrumMaster 分身兩個團隊與讓一位 ScrumMaster 兼任開發工作之間選擇。作者傾向將時間分給兩個團隊。兼任的風險包括：時間不足、需要避開關鍵路徑工作、團隊成員分不清對方是以 ScrumMaster 還是個人身份說話、保護團隊免受外部干擾時可信度較低。

ScrumMaster 替團隊做決策：ScrumMaster 應該提供引導而非答案。作者分享他自己的經驗——當團隊在會議中遇到棘手問題並期待他給出「答案」時，他學會了默默數數 1, 2, 3……直到團隊自己找到答案。

Product Owner#

作者認為 ScrumMaster 是確保團隊運作良好、障礙被快速移除、團隊高效前進的人。而 Product Owner 則是確保團隊瞄準正確目標的人。好的團隊需要兩個角色都成功：Product Owner 將團隊指向正確的目標，ScrumMaster 幫助團隊盡可能高效地達到目標。

Product Owner 的職責#

Product Owner 為團隊提供兩樣東西：願景 (Vision) 和邊界 (Boundaries)。

提供願景：最好的團隊是被 Product Owner 分享的引人注目的願景所點燃熱情的團隊。Product Owner 透過創建、維護和排序 Product Backlog 來闡明願景。Product Owner 不一定要親自撰寫 backlog，但必須確保它存在並被正確維護。Product Owner 還透過回答團隊的問題來為願景添加細節。

提供邊界：邊界描述了願景必須在其中實現的現實，通常以約束的形式出現，例如：

• 六月前需要完成
• 需要將單位成本降低一半
• 速度需要提高一倍
• 只能使用目前版本一半的記憶體

Product Owner 的工作是創造新的「盒子」——團隊在其中思考的邊界。這個盒子防止團隊迷失在無限的可能方案中，同時給予團隊比較和選擇的基礎。

每個團隊需要恰好一位 Product Owner#

對新接觸 Scrum 的團隊，ScrumMaster 的工作量會非常大（培訓、引導、移除障礙），甚至可能是全職。但隨著時間推移，團隊掌握了 Scrum 並擁抱自組織，對 ScrumMaster 的需求會逐漸減少。

相反地，對 Product Owner 的需求會逐漸增加：隨著團隊加速並完成更多工作，他們會有更多問題需要 Product Owner 回答。

這種反向關係意味著：

• 一位有經驗的 ScrumMaster 可以同時服務兩到三個團隊
• 不建議一位 Product Owner 跨越兩個以上的團隊
• 每個團隊理想上應有自己的專屬 Product Owner

一個團隊只應有一位 Product Owner。如果一個團隊有兩位 Product Owner，將不可避免地陷入「媽媽說不行，我們去問爸爸」的困境。

Product Owner Team#

在某些情況下，Product Owner 的工作量對一個人來說太大。常見的解決方案是使用 Product Owner Team，將職責分散給多人，但仍需有一個人被視為擁有最終責任和權威的「the-buck-stops-here」角色。

優秀 Product Owner 的五大特質 (ABCDE)#

記住這五個特質很簡單——每個特質的首字母拼成 ABCDE。

Available（可用的）：團隊對 Product Owner 最常見的抱怨是在需要時聯繫不上。快節奏的團隊等三天才得到答案，對團隊的節奏是完全破壞性的。最好的 Product Owner 願意做任何必要的事來打造最好的產品。

Business-savvy（懂商業的）：Product Owner 必須對商業、市場狀況、客戶和使用者有深入的理解。這就是為什麼許多成功的 Product Owner 來自產品管理、行銷或商業分析背景。

Communicative（善於溝通的）：Product Owner 必須能與多元的利害關係人良好合作——使用者、客戶、組織內管理層、合作夥伴和團隊成員。好的 Product Owner 能向不同受眾傳遞相同資訊，同時根據受眾調整訊息。Product Owner 也必須善於傾聽團隊的意見。

Decisive（果斷的）：團隊常抱怨 Product Owner 缺乏果斷。在快速產出的壓力下，Product Owner 回應「讓我開個會議」會讓團隊挫折。好的 Product Owner 不會無充分理由推翻先前的決策。

Empowered（被賦權的）：Product Owner 必須有足夠的權力做出決策並對其負責。如果 Product Owner 的決策不斷被組織中其他人推翻，團隊成員會學會直接去找那些人。

ScrumMaster 兼任 Product Owner#

作者不建議合併這兩個角色。原因是：

• 將大量權力集中在一人手中
• 對團隊成員和兼任者本身都造成困惑
• Product Owner 與 ScrumMaster 之間應存在一定的張力——Product Owner 持續要求更多功能，ScrumMaster 在覺得過度壓榨團隊時進行反推。合併角色會消除這種張力。

雖然 Toyota 以其「首席工程師」角色成功結合了這兩個角色，但作者認為能同時勝任兩者的人非常罕見，建議在轉型初期使用不同的人擔任這兩個角色。

克服常見問題#

Product Owner 授權後又推翻決策：建議 Product Owner 在授權前確認自己真的願意放手。建議嘗試授權到「略超出舒適圈」的程度。如果被授權者做了一個不算糟糕的決定，讓它持續到 sprint 結束再評估是否需要改變。

Product Owner 對團隊施壓過大：Product Owner 在交付業績的壓力下，可能持續逐 sprint 施壓。一個有挑戰性但給予充分自由的長期目標（如「在六個月內完成這件了不起的事」），比 13 個連續的兩週 sprint 都喊著「要更多更多」壓力更小。ScrumMaster 應反推並協助 Product Owner 設定更長期的目標。

Product Owner 想要削減品質：Ken Schwaber 稱品質為「企業資產 (corporate asset)」。除了最高主管，沒有人應該有權為了短期目標犧牲品質。ScrumMaster 不一定需要在這些早期爭議中勝出，但需要成功地讓削減品質的決策變得可見。時間站在 ScrumMaster 這邊。

Product Owner 與開發團隊不在同一城市：這種情況越來越常見。只要 Product Owner 做到以下幾點，遠端也能成功運作：

• 保持對專案的投入
• 與團隊建立融洽關係
• 執行角色的所有常規職責
• 至少在一天的部分時間可以接聽電話
• 不在場時透過電子郵件或電話回應

新角色，舊責任 (New Roles, Old Responsibilities)#

雖然 Product Owner 和 ScrumMaster 的角色是新的，但其責任並不是新的。高績效團隊一直都知道他們需要做本章所描述的事情。在 Scrum 團隊中，個人被要求超越其明確的角色，找到方法幫助團隊達成目標。

在下一章中，我們將探討這種對團隊合作和共同責任的新強調，對組織中既有角色意味著什麼。