官方《Scrum指南》中定義：Scrum Master在Scrum團隊中屬於服務型領導，負責踐行和支援《Scrum指南》中定義的Scrum，要幫團隊的每個人理解Scrum理論、實踐、規則以及價值觀。
最近我們進行了一次調查，其中92％的受訪者表示他們正在實踐的scrum是按需訂製的，而非“按章辦事”。這讓我們想知道，這對扮演訓練和幫助團隊理解scrum角色的scrum master來說意味著什麼？ 這些scrum master是如何適應不斷發展的且有別於官方規定實踐的敏捷世界的？
為了回答這些問題，我們對敏捷行業的無名英雄——scrum master的角色和責任進行了深入研究。
Scrum Master是什麼？
Scrum Master是scrum的推動者。scrum是一種輕量級敏捷框架，專註於實現固定時間的迭代，也被稱為sprint。作為推動者，scrum master充當團隊其他成員的教練，在《Scrum指南》中被稱為“服務型領導”。優秀的scrum master致力於構建scrum的基礎和價值觀，同時保持一定的靈活性和開放性讓團隊有機會改進工作流程。
1.Scrum Master的職責
在理想的敏捷世界中，團隊可以管理自己的流程和工具。然而，我們發現許多團隊通常需要依賴scrum master作為其流程的主導者才能實現敏捷的飛躍。要實現對團隊的掌控，並履行職責，scrum master需要花費大量的時間。在這種變革性的背景下，scrum master的工作可以很輕鬆，如僅安排scrum相關儀式；也可以很繁重，像團隊的其他成員一樣深度參與整個過程。儘管《Scrum指南》列出了scrum master應該如何為其他角色提供服務，但關於scrum master的責任義務並沒有詳細列出來。事實上，我們發現，scrum master通常需要執行下面部分或全部並沒有在scrum中定義的工作：
1.站會 ——根據需要促成每日站會（或每日scrum會）。
2.迭代/sprint規劃會 ——確保團隊不會承擔過多或超出能力範圍。幫助團隊進行估算及子任務的創建。
3.sprint評審會 ——參加會議並記錄回饋。
4.回顧會議 ——記錄需要改進的領域和後續sprint的行動項目。
5.委員會管理 ——承擔Scrum委員會的管理工作。並且保證資訊的即時性及Scrum工具（Worktile或其他工具）運行良好。
6.一對一談話 ——根據需要與團隊成員和利益相關者單獨談話。化解團隊對在流程和工作方式等方面的分歧。然而許多scrum從業者都反對一對一談話，因為他們認為這些交流應該在每日站會上進行，一些團隊，特別是新團隊，更傾向於請scrum master與個別團隊成員定期進行面對面交流。scrum master則認為這些單獨的交流互動對於團隊發展和成員之間的彼此了解至關重要。
7.內部協商 ——scrum master應該與團隊成員和內部利益相關者進行協商，就如何更好地與Scrum團隊合作達成一致。
8.報告 ——定期分析燃盡圖和其他投資組合規劃工具，以了解團隊正以什麼樣的節奏構建產品。
9.護航者 ——scrum master通過消除外部障礙和改進過程或工作流管理內部障礙等方式為團隊提供支援。
10.代勞雜務 ——如果scrum團隊沒有處於忙碌的狀態，那就是scrum master的問題。因為這意味著團隊可能在修理壞掉的電腦、挪動周圍的桌子甚至調整恆溫器。Scrum master應該隨時準備好做任何可以幫助團隊的事。如果團隊真的需要的話，scrum master甚至需要為成員準備咖啡和零食，以確保成員不需要在此類雜事上浪費時間或趁機磨洋工。
2.你的團隊是否需要一個scrum master？
任何一個scrum培訓師都會告訴你，每個scrum團隊都應該有一個scrum master。如果沒有，那麼你們的scrum就算不上真正的scrum，經常被叫做scrum-but。
在團隊剛開始嘗試scrum的時候，有一個具備scrum工作經驗的scrum master可以帶來很大的幫助曾，當然，曾經見證過很多scrum成功案例者更佳。也正因為這個原因，很多scrum master經常被聘用來擔任顧問，而非全職員工。
但每個scrum團隊都是獨一無二的。很多經驗豐富的團隊承擔前面列出的所有關於scrum master的責任，享受由團隊成員共同管理的流程並為此感到自豪。這種情況下，scrum master的角色將由團隊成員輪流承擔，並輪流組織召開每日站會和回顧會議。
而對於一些團隊來說，正確的做法就是請一個專業人員來擔任scrum master。
不幸的是，由於對scrum master角色存在誤解，所以經常導致現任管理者認為scrum master是他們崗位職責的一部分。為了更好的理解為什麼這樣做會造成問題，以及為什麼要在組織中單獨設立scrum master的角色，我們將scrum master的角色與組織中現存的非scrum角色來做一個對比。
Scrum Master和產品經理
正如我們在《敏捷產品管理概述》中提倡的那樣，產品經理與開發團隊之間的互動越多越好。這種互動應該與產品負責人的想法保持一致：支援客戶需求且清楚為什麼開發這款產品。但如果這種互動模糊了任務-即團隊該怎麼實現功能，那就說明互動存在問題。儘管出發點很好，但這種利用型心態會導致問題被隱藏或掩蓋，如：缺陷、交接和未知問題等。交錯範圍和進程很容易鎖定範圍、進度和品質，而這註定導致失敗。
這就是為什麼scrum master和產品負責人在scrum團隊中分別滿足兩個不同需求的原因，但這兩個角色在傳統軟體管理中通常是由一個人來擔任。規模較小的團隊也很容易就為了節約支出而省掉scrum master這個職位。只是，一旦有障礙出現或變動發生，團隊就需要在流程管理和產品方向之間進行明確劃分。
團隊中如果有scrum maser就可以幫助團隊實現因改變產品方向所帶來的消耗和由效率提升所帶來的收益二者之間的平衡。一個優秀的scrum master通過賦予團隊權利，讓他們自行決定如何通過自組織的方式以最好的方式實現目標。
Scrum Master和項目經理
在非技術（或非敏捷）領域與scrum master角色對應的是項目經理的職位。這兩種角色都專註於“如何”完成工作並通過過程和建導解決工作流程的問題。那麼我們是否同時需要這兩個崗位呢？大多數情況下是不需要的。
傳統的項目經理和scrum master都有責任幫助他們的團隊完成工作，但他們的方法卻截然不同。項目經理設定時限和里程碑、報告進度並協調團隊溝通。從控制的角度實施工作，扮演一個比較傳統的管理者角色。
Scrum Master則旨在幫助團隊強化和精簡實現目標的流程。理想狀態下，他們是以團隊成員或協作者而不是控制者的身份開展工作。最好的Scrum團隊是自組織的，因此自上而下的管理不會取得好效果。
這只是一些Scrum團隊管理的一些建議配置。有些團隊配備所有角色，有些組織設置一個或根本沒有。
Scrum Master能為組織帶來更大收益
在考慮是否聘請scrum master的時候，有一個考量因素優先於其他任何因素，即：只有在您的組織致力於scrum並願意投資這個流程時才聘請。以上提到的各類管理角色都可以通過多種方式管理開發團隊，但scrum master只有在100%投入scrum時才有效。
通過scrum master幫助每個團隊管理他們的流程，整個組織可以獲得一些重大收益。除了定期向客戶提供交付價值（scrum的主要目標）外，團隊成員和經理可以自由地專註於他們擅長的事。產品經理專註於戰略、開發人員專心寫程式碼，而銷售人員則全身心的開發客戶。這像什麼？這就是高效運作的scrum團隊該有的樣子，也是我們最期待的場景。
作者：MAX REHKOPF
翻譯/校對：Worktile
文章來源：Worktile敏捷部落格
