Scrum Master 這個在 Agile Scrum 框架之中的一個角色，常常是大家很關注的話題，但其實這個角色到底做些什麼事情、該由誰擔任，也是很多人很好奇或有滿腹疑惑的地方，常常會在社群分享的場合聽到下面的疑問:
- Scrum Master這個角色到底做些什麼?
- 該由什麼樣技能背景的人來擔任?
- 怎麼決定誰來擔任這個角色的?
- 這個角色可是 開發成員 或 部門主管 兼任一下嗎?
(特別是許多剛接觸scrum概念的人，或有想要進行敏捷轉型的單位，特別會有這種問題)
網路上可以蒐尋找到一堆scrum master的職責、定義，但Scrum Master的活動，到底像是什麼樣子，每天做些什麼，這些工作會花費這個角色多少時間，網路上的分享卻很少。
有些剛初接觸Agile Scrum的人，覺得這Scrum Master好像團隊內隨便抓個人來做就行，但在網路上爬了文之後，看到這個角色很多的定義與執掌，又覺得這角色包山包海，又能溝通又懂流程，簡直是要找個神人來才有辦法進行。
也因此，籍由本文先就我個人在Project GATE這個專案中，身為一個Scrum Master的角色下的工作項目以及其細節展開，藉此也讓有興趣的人透過生活照圖文了解一下，並從中反思，「為什麼 Scrum Master 由一個不負責工作開發的人來負責」、「Scrum Master需要具備什麼樣的特質及技能」
Part 1 - Sprint 進行中的日常工作 (Sprint Duty)
主持各類scrum活動會議
planning sum up 會議
- 前置整理實際要開發的條目
- 閱讀並檢查每一個被團隊挑選的user story
- 是否有設定iteration / point(是否有輸入) / task時數(檢查時數是否合理)
- task scope與 story描述是否合理
- 預告本sprint預計會進行的會議並booking meeting時間
- 主持會議
daily scrum
- 統計消化時數 (實體看版)
- 更新圖表 (實體看版 & 電子化資料)
- burn-down, bug report, crash status
- Milestone 時間軸移動
附圖1. Scrum Master在旁邊拿著手機，用著計算機app來算著大家的消化時數
附圖2. Scrum Master更新數據於實體看板上
polish time
- 預告Polish活動
- 主持polish time 並主持總結
(註: polish time 是全team於sprint review前兩天，不分身份角色，一起自食狗食的時刻，讓大家可以透過實際使用去感受成品並發言提出見解)
review meeting
- 會前確認各review版本狀態
- 安排各小組的展示時間與順序
- 主持並進行會議紀錄，視情況決定在自省會議是否討論
- 引導進行檢閱電子化專案追蹤系統的狀態，確保sprint的結束狀態是同步及透明的。
- 品質報告狀態
附圖3. Scrum Master 於 review meeting 主持議程
自省retrospective meeting
- 提前整理前幾次會議的結論。
- 主持會議並整理要點 (real time processing)。
- 帶領 team member討論各種情境的成因、行動方案 或需另外舉辦會議討論。
- 提醒refinement meeting booking。
附圖4. 有幾次sprint failed，Scrum Master則介紹了 5-whys + 魚骨圖 的要因分析的方法，然後帶著團隊進行 sprint failed 的團隊自我檢討。
Part 2 - 不定期發生 (Executive Duty)
Project Duty:
- 檢閱專案的中長期報表(cumulative flow, bug statistic, 各種leading/cycle time)並與團隊溝通解決其中的問題。
- 蒐集並更新release roadmap
- 主持release planning
- 敏捷式召募規畫及執行
- 敏捷式協作空間的規畫與討論
- 參與Product Owners會議
- 參與Stakeholder會議
- 新進成員的Agile Training
附圖5-1. offsite meeting 的場勘，提前確認地點是否合宜並一起規劃活動。
附圖 5-2. offsite meeting的場外活動，scrum master跟著PO一起場勘，因為要在戶外實際使用自己開發的app，所以途中一直要以3G iPad不斷的確認訊號強度狀況，並規劃出合宜的活動(或藉機讓團隊體會什麼情境)。
附圖 5-3. 參與offsite meeting 的活動設計，也包含了許多引導團隊思考及討論、分類、規劃，以及創意提案競賽等活動(所有的活動其實都隱含著許多的敏捷、團隊精神及工法的引導)
- 引導團隊形成共識及規範。
- 確保並引導團隊成員按照團隊的規範與共識在進行。
- 觀察團隊平常的協作及活動，並紀錄這些事件與現象。
- 參與成員的績效考核或新人考核，並提供相關參考資訊。
- 閱讀並消化敏捷相關議題的文獻、找尋合適的解決方案去解決團隊的問題。
- 檢閱現有的開發流程、引導優化並確保成員遵守。
- 360度協作與溝通
附圖6. 與單位主管們一起規劃出來的敏捷團隊協作空間。而Scrum Master 平時的位子位在看板區前，並且是一個方便做觀察者的樞鈕區(互動熱點區附近，可不動聲色的觀察中)
這兩部份所花的時間比例如下:
註: 時間參考的部份，是2014年四~五月間，透過Toggl這個 Time Tracking tool 記錄了一些Scrum Master的流水帳，所整理出來的。不過，這個比例其實並沒有把下班後投入的自修時間算在內。而且這個比例也隨著團隊的當時狀況，都可能有也都會有大比例的變動。
而Scrum Master最忙的時刻，其實是這些會議的前置準備期及主持這些會議。
而成員在開發的期間，Scrum Master做的事情其實就很多元跟鎖碎了，也因此，確保自身的敏捷化、適應性 對Scrum Master而言異常重要。大家可以想像一下，只要開發團隊中有出現了某些跡象，Scrum Master的天線就要對準這些發生點進行觀察，自己正在做的事情有時就需要停下來了，甚至必要時當下就要進行排解。
而成員在開發的期間，Scrum Master做的事情其實就很多元跟鎖碎了，也因此，確保自身的敏捷化、適應性 對Scrum Master而言異常重要。大家可以想像一下，只要開發團隊中有出現了某些跡象，Scrum Master的天線就要對準這些發生點進行觀察，自己正在做的事情有時就需要停下來了，甚至必要時當下就要進行排解。
當然有些巷子內的看倌們可能會發現，我怎麼沒提到Scrum裡面一定會有的 planning meeting 與 refinement meeting ? 怎麼這個team中的scrum master從裡面人間蒸發了?
以結論而言，主要是因為近期的團隊與project scope增長，這兩個events 已經演進到是 multiple tracks同時進行，一方面是我沒有練分身術，一方面是成員也都已經都能掌握精神，所以我這個Scrum Master就變成只是列席，團隊有需要時再出席，只進行場外追蹤。
大家可以再回頭想想:
Scrum Master這個角色該由什麼樣子技能背景的人來擔任?
延伸思考:
是 Scrum Master? 還是 Agile Coach?
是 Scrum Master? 還是 Agile Coach?
---
延伸閱讀:
The Agile Coach role at Spotify
