本章描述 ScrumMaster 角色，涵蓋其目的、主要職責、特質與技能、日常時間分配，以及誰應擔任此角色、是否為全職工作，以及與其他角色的組合方式。

概述#

ScrumMaster 是構成每個 Scrum 團隊的三個角色之一。如果說 Product Owner 專注於「建造正確的產品」，開發團隊專注於「正確地建造產品」，那麼 ScrumMaster 專注於幫助每個人理解並擁抱 Scrum 的價值觀、原則和實踐。

ScrumMaster 同時扮演：

• 開發團隊和 Product Owner 的教練（Coach）
• 流程領導者（Process Leader），幫助 Scrum 團隊和組織發展出適合自身的高績效 Scrum 方法

主要職責#

教練（Coach）#

ScrumMaster 是 Scrum 團隊的敏捷教練——同時教練開發團隊和 Product Owner。如同運動隊伍的教練，ScrumMaster 觀察團隊如何使用 Scrum，並盡一切可能幫助團隊達到下一個績效等級。

面對問題時的態度：

• 對於團隊能夠且應該自行解決的問題：「我不是來替你們解決問題的，而是來幫助你們解決自己的問題」
• 對於團隊無法自行排除的障礙：ScrumMaster 負責承擔並推動解決

ScrumMaster 與 Product Owner 的關係如同運動隊伍教練與球隊老闆：幫助老闆用 Scrum 最大化業務成果、管理期望、確保老闆提供團隊所需、傾聽抱怨並轉化為團隊可執行的改善。

僕人式領導（Servant Leader）#

ScrumMaster 首先是 Scrum 團隊的僕人，確保團隊最高優先的需求被滿足。

僕人式領導者不會問：「你今天要為我做什麼？」而是問：「我今天能做什麼來幫助你和團隊更有效？」

流程權威（Process Authority）#

ScrumMaster 被授權確保 Scrum 團隊執行並遵循 Scrum 的價值觀、原則和實踐，以及團隊特有的方法。ScrumMaster 持續協助團隊改善流程，盡可能最大化交付的業務價值。

這裡的「權威」與功能主管或專案經理的權威不同。ScrumMaster 不負責聘雇與解雇、不能指示團隊做什麼任務或如何做、也不負責確保工作被完成。ScrumMaster 是幫助團隊定義並遵循自己的流程來確保工作被完成。

干擾屏障（Interference Shield）#

ScrumMaster 保護開發團隊免受外部干擾，使團隊能專注於每個 Sprint 交付業務價值。干擾可能來自：

• 想在 Sprint 中途重新指派團隊成員的主管
• 其他團隊引起的問題
• 各種外部詢問和爭議

ScrumMaster 充當攔截者，接收詢問、應對管理層、調解爭議。

障礙移除者（Impediment Remover）#

當團隊成員無法合理地自行排除障礙時，ScrumMaster 負責承擔移除的責任。

實例：一個 Scrum 團隊持續無法達成 Sprint 目標，障礙是用於測試的不穩定生產伺服器。團隊無法控制這些伺服器（由營運副總負責），因此 ScrumMaster 承擔了與營運副總及相關人員合作以改善伺服器穩定性的責任。

變革推動者（Change Agent）#

ScrumMaster 不僅要排除技術障礙，還要改變人們的思維。Scrum 對現狀的破壞性可能很大，成功所需的改變可能很困難。ScrumMaster 的職責包括：

• 幫助他人理解變革的必要性
• 說明 Scrum 對 Scrum 團隊以外的影響
• 傳達 Scrum 可以幫助達成的廣泛效益
• 確保組織各層級都有有效的變革發生
• 在大型組織中，ScrumMaster 們可能聯合起來成為更有效的變革力量

特質與技能#

知識淵博（Knowledgeable）#

• 必須對 Scrum 非常精通
• 應理解團隊需要處理的技術議題和使用的技術（不需要達到 Tech Lead 等級，但合理的技術知識是加分項）
• 不需要是業務領域專家（那是 Product Owner 的事），但了解業務領域的工作知識很有幫助

善於提問（Questioning）#

ScrumMaster 運用教練技能搭配流程、技術和業務知識來提出好問題——讓人停下來說：「嗯，我從沒想過這個。你這個問題讓我覺得可能有另一種方式。」

好的 ScrumMaster 幾乎從不直接回答問題，而是用自己的問題回應——不是令人煩躁的問題，而是深思熟慮、深入探究的問題（一種蘇格拉底式提問），幫助人們意識到他們有能力找到自己的答案。

有耐心（Patient）#

因為 ScrumMaster 傾向不直接給答案，他們需要耐心，給團隊時間自行得出適當的答案。

作者坦言：身為 ScrumMaster 有時很難忍住，因為看到問題時「知道」答案。但認為自己比團隊的集體智慧更聰明是傲慢的。有時就是要忍住，讓團隊自己找出解決方案，適時用探究性的問題引導方向。

協作（Collaborative）#

ScrumMaster 需要出色的協作技能，與 Product Owner、開發團隊和所有其他相關方合作。作為流程教練，ScrumMaster 也持續尋找機會幫助團隊成員達到令人稱羨的團隊內部協作水準。

保護性（Protective）#

ScrumMaster 像牧羊犬一樣保護團隊：

• 守護羊群免受「狼」的攻擊（組織障礙或有不同議程的人）
• 在團隊保護和業務需求之間取得健康的平衡
• 幫助偏離方向的團隊成員回歸——當事情變得困難時，人們容易退回到熟悉的非敏捷方法，ScrumMaster 要幫助他們重新學習更有效地使用 Scrum

透明（Transparent）#

ScrumMaster 在所有溝通形式中都是透明的：

• 沒有隱藏議程——所見即所得
• 作為僕人式領導者，人們期待的就是如此
• 也促進 Scrum 團隊之外的透明溝通——沒有透明的資訊存取，組織難以進行檢視與調適

一日之生活#

上圖為新成立團隊的 ScrumMaster 在一個 Sprint 中的大約時間分配（高績效團隊的分配會不同）：

障礙移除是 ScrumMaster 日程中最大的變數。 剛接觸 Scrum 的團隊和組織通常在起步時有很多障礙，初期集中處理較明顯且容易移除的。但下一層級的障礙往往更加困難且耗時。

角色實踐#

誰應該擔任 ScrumMaster？#

組織中不會有現成的「ScrumMaster」角色，好的 ScrumMaster 可能來自多種背景：

• 前專案經理或產品經理（產品經理更可能轉型為 Product Owner）
• 開發、測試或其他技術背景
• 只要具備前述特質且願意承擔職責，任何人都可以成為有效的 ScrumMaster

關於技術領導擔任 ScrumMaster：

Tech Lead 或 Dev Lead 可能是好的 ScrumMaster，但也可能不是最佳選擇。他們的技術卓越在 ScrumMaster 角色中無法被完全發揮——他們做 ScrumMaster 工作的時間，就是少提供技術領導的時間。

關於功能主管擔任 ScrumMaster：

功能主管也可以成功擔任 ScrumMaster，但最好不再對其 Scrum 團隊成員保留人事管理責任。ScrumMaster 沒有管理權限，團隊成員可能會混淆此人當下戴的是 ScrumMaster 的帽子還是主管的帽子。

ScrumMaster 是全職工作嗎？#

• 合作時間長且精通 Scrum 的團隊可能比新團隊需要更少的教練
• 但隨著團隊對 ScrumMaster 的日常需求減少，ScrumMaster 聚焦於更廣泛的組織障礙和作為整個價值鏈的變革推動者的需求通常會增加
• 在多數情況下，ScrumMaster 角色仍是顯著的時間承諾

ScrumMaster 與其他角色的組合#

ScrumMaster + 開發團隊成員：

若容量允許且同一人是優秀的 ScrumMaster 和開發團隊成員，可以身兼兩職。但可能面臨利益衝突——當有重要的 ScrumMaster 活動（如障礙移除）和關鍵的任務級工作同時存在時，犧牲任何一方都會降低團隊效能。障礙的不可預測性使得更難預估 ScrumMaster 兼團隊成員實際可用於任務級工作的時間。

作者偏好的替代方案：若 ScrumMaster 確實有閒餘容量，讓該人擔任多個 Scrum 團隊的 ScrumMaster，而非花時間做非 ScrumMaster 的活動。成為好的 ScrumMaster 需要一套有價值且不常見的技能，讓擁有這些技能的人與多個團隊分享更為理想。

ScrumMaster + Product Owner（強烈不建議）：

• ScrumMaster 是 Scrum 團隊的教練，包括教練 Product Owner——很難當自己的教練
• Product Owner 有實質的產品權限且可以對團隊提出要求
• ScrumMaster 經常扮演 Product Owner 的要求與開發團隊的需求和能力之間的平衡角色
• 讓兩個角色由同一人擔任只會增加本可輕易避免的混淆