開始點敏捷的工程師
因緣際會下接下了公司團隊的 Scrum Master 角色，從 2022 六月開始至今已經擔任了六個月的時間，希望用此篇記錄一下我在這個職務下所見所得，希望可以幫助跟我一樣是第一次接觸或承接這樣職務的人。
前言與背景
因為此篇重點會是講述我擔任 Scrum Master 的經驗與歷程，所以會以「認為讀者都對 Scrum 有一定認知」的前提下寫這篇文章，如果對於我文中提到的相關名詞有疑問，透過 Google 應該都可以找到解答，謝謝見諒！
# 成為 Scrum Master 的契機
我在目前的公司已經任職「前端工程師」三年多時間，我們公司除了一些真的很大型的產品團隊之外，大部分團隊的 Scrum Master 都是由 PO/PM 兼任，但剛好我所屬的產品團隊近期進入了產品快速發展時期，大量的專案開發加上產品的運營和維護，讓我們的 PM 實在沒有辦法額外負荷 SM 的工作，所以在主管的考量下，希望由我來兼任 SM 角色，好減輕 PM 的負擔。
再加上由於工程的人力相對來說比較充裕，以及主管的信任等因素，我就這麼接下這個職務了。
旅程開始
# 成長曲線
首先我想用一張簡單的曲線圖來說明一下我這六個月的成長階段，透過這張圖可以看出，我經歷了三個階段，而這三個階段的轉變時機則是透過「Scrum 讀書會」促成的，後面我便會從這三個階段及兩個轉捩點來說說我的經歷。
這邊也提前先說明一下，圖上的「Scrum 讀書會」是由產品團隊的一位成員發起的活動，邀請所有團隊成員提前閱讀 2020 新發布的 Scrum Guide 以及 2022 Regional Scrum Gathering 活動的 前導影片，最後在讀書會當天各自提出見解與問題來進行交流討論。
# 階段一：團隊秘書 & 行政管理
我的心情
因為我一開始是對 Scrum Master 實際職責其實是一知半解的，所以我並沒有太多的緊張，反而蠻平常心的，認為只是多處理幾件行政庶務而已。
我做了什麼
在這個階段裡，基本上我做的工作就只是提醒成員開會，並按照過去的流程依樣畫葫蘆，以及把成員的任務進度及狀態做些簡單的管理與追蹤等...沒有做什麼太複雜的工作。
踩到什麼誤區
就如這個階段的標題一樣，我在這個階段所扮演的角色，其實就是「團隊秘書與行政」，工作項目都是一些雞毛蒜皮的小事。而我想這正是因為我對 Scrum Master 的理解太過片面，我對以往 SM 的觀察太過表面，以至於只能模仿，卻無法理解 Scrum 的深層內涵。
# 轉變：Scrum 讀書會準備期
第一階段在維持了大約 2 個多月之後，團隊便有了舉辦讀書會的規劃，讀書會的召集人給了我大約兩個禮拜的時間，讓我們閱讀 Scrum Guide 和相關影片，並在讀書會當天要發表一段自己的觀看心得，同時也可以提出自己的疑問和大家討論。
接觸到的新事物
領悟及感受
- 在看過了這些相關資料之後，我才發現原來 Scrum Guide 有提到不少概念和原則，而且好像有些東西是目前團隊沒有做到的。會說「好像」是因為 Scrum Guide 的部分內容並不是那麼具體，所以我實際上是「感覺」我們沒做到。
- 「那既然沒有完全遵照 Scrum Guide 還是可以好好工作，那差別在哪？」是當時一個油然而生的感受，因為我發現公司內的每個團隊遵循 Scrum 的程度有高有低，但身為開發人員的我．似乎在工作上也沒有太大的差別。
- 在看過這些資料或其他網路文章時，大家都會宣揚說 Scrum 能夠帶來什麼好處，但卻沒什麼人會跟你說你應該要怎麼一步步的實踐它，這讓我感到很困擾。
# 階段二：超級英雄 & 敏捷警察
我的心情
隨著開始準備讀書會，我開始進到第二個階段，在這個階段裡我的心情其實有點複雜。
因為就如前面所說的，我其實有點懷疑遵循 Scrum 的意義，不過身為團隊的 SM，我又覺得還是有責任要讓團隊的各個規範對齊 Scrum Guide，但 Scrum Guide 的內容又有不是很具體，所以儘管我很想嘗試做些什麼，卻又不知道該從何開始，導致我也會開始懷疑自己，變得很緊張。
我做了什麼
在這個階段裡，我做的工作基本一樣，只不過我會一直找各種文章來看，希望從中得到指引，或是希望團隊成員能給我一些具體的意見，讓我知道我接下來該做接什麼，才能將 Scrum 真正地在團隊內運作。
踩到什麼誤區
後來回頭看看這個階段並自我檢討後，才發現我有點太心急了，自認為 Scrum Master 要幫成員準備好一切，只要有哪個環節不符合 Scrum Guide 就會覺得不對勁，一直想要做些什麼來證明我是可以擔起這個職務的。所以這個階段才會被我稱作為「超級英雄與敏捷警察」。
並且現在我也才知道，Scrum Guide 其實就像是媽媽在家裡教你做菜，她不會告訴你鹽要加多少，或是肉要燉多久才會嫩，因為實際在品嚐的是你與你的成員，所以你應該自己找到符合你們的調味，而不是期待 Scrum Guide 像一本食譜，總是給你明確的數字與步驟。
# 轉變：Scrum 讀書會結束後
第二階段其實並沒有維持很久，因為在讀書會結束之後，我大該花了一兩天的時間去釐清跟整理，就讓我有了新的領悟跟想法。
接觸到的新事物
- 讀書會中成員的想法
- 無數的網路文章
領悟及感受
- 在讀書會中，其實每個團隊成員都有提出他們找到的問題與改善的方向，這時候就會感受到其實一個團隊該如何運作 Scrum 並不是 SM 一人的責任，而是整個團隊要一起不斷的檢討與改善才能成型。
- 另外也獲得一個資訊，是大部分的成員都對 Sprint Goal 和有蠻大的關注，所以我認為這可能會是我第一個可以下手改善的部分。
最後我整理了大家的想法並且自己反覆看了一些網路文章後，我終於理出一個自己身為 SM 該完成的終極目標： 因為完成 Sprint Goal 代表團隊產出了價值，而且會為成員帶來向心力及成就感，所以
想辦法提升 Sprint Goal 的完成機率與程度就對了
邁向 Master 的途中
經歷了前面的兩個階段與轉變，我認為我目前已經開始慢慢步向正軌，朝著真正的 Scrum Master 前進，所以我稱這個階段為「邁向 Master 的途中」，雖然因為我目前正處於這個階段，所以還不太能為這個階段做一些比較完整的總結，不過我還是希望把這個階段額外拉出來，和大家分享一下截至目前為止我在這個階段所做的一些行動。
# 心智圖
首先，因為已經在讀書會結束之後找到了我作為 Scrum Master 的終極目標 - 提升 Sprint Goal 的完成機率與程度，所以我做的第一件事情是以「Sprint Goal」為題，進行心智圖的繪製，透過不斷地向自己提問「Why? What? How?」來產生分支，然後再以完成終極目標的前提去回答這些問題，如此一來 Sprint 中的每個環節就更可以知道如何執行。
後面我就會透過三個案例來說明我是如何利用這一套心智圖框架來和團隊一起改善現有流程的。
# 目前的 Planning 有什麼可以改善的？
我觀察到的現況
- 首先比較弔詭的是，我們團隊其實沒有訂定過 Sprint Goal，大家只能看著一連串的 Sprint Backlog 來大概感受產品在這個 Sprint 的走向。
- 另外每次在召開 Planning 之前，確切的任務工單是沒有被列出來的，都是先透過 PM 口頭說明的方式來大致了解這個 Sprint 的工作項目。
問題
- 由於沒有 Sprint Goal，導致團隊成員對 Sprint 沒有共識，焦點會分散在各自的任務上而缺乏凝聚力，對於任務的意義性與重要程度也會沒有明顯感受。
- 沒有明確的任務數量、範疇、排序等資訊，則會影響成員預估工時的準確性，最後就可能會讓 Sprint Backlog 做不完，使得 Sprint Goal 的完成度降低。
改善方式
- 首先當務之急，當然是請 PM 在每個 Sprint 開始前先訂定一個初步的 Sprint Goal，等到 Planning 時，在與成員討論並定案。
- 而為了增加工時估算的精準度，我也請 PM 前一定要將所有工單建立完畢，並按照握們這次的目標制定任務的優先順序，而在 Planning 時，也要請成員預估自己在這個 Sprint 可以花費的時間，若認為時間不夠，才可以在當下將部分任務排除，進而提升 Sprint Goal 的完成度。
架構套用
- 因為要提升 Sprint Goal 完成度 → 所以必須要先有 Sprint Goal
- 因為要提升 Sprint Goal 完成度 → 所以一開始就要精確的圈出可完成的範圍，否則沒完成的任務將降低完成度
# 目前的總結會議(Review + Retrospective)有什麼可以改善的？
我觀察到的現況
- 目前 Review 的回顧方式是請所有成員將自己手上的任務說明一遍狀況，沒有固定形式，大家說明的詳細程度也不一樣，感覺只是一場大型的站立會議。
- Retrospective 的流程是固定不變的，所以感覺成員有點出現疲態。
問題
- Review 沒有具體展現團隊在這個 Sprint 完成了什麼事以及 Sprint Goal 的推進，而是只有個別成員的工作日誌，成員缺乏目標感以及成就感。
- Retrospective 中，團隊成員的重點都放在感謝與自我檢討，缺乏團隊的核心問題思考，Retro 應該是用來改進團隊運作與流程的時間。
改善方式
- Review 的第一件事應該是回顧所有工作項，並計算完成與未完成的項目，就可以求得這個 Sprint 的 Sprint Goal 完成度，具體的數值才能讓成員感受到實質的產品推進，而非用感覺的。
- 取消工作日誌式的報告，取而代之的是「成果發表」，請該 Sprint 有完成任何「價值」的成員在會議中用簡報形式向整個團隊展示成果，除了增加個別成員的成就感，也能讓整個團隊真正了解這個 Sprint 我們達成了什麼。
企劃、設計、功能開法、研究報告等...都是可以發表的內容。 - 經常變換 Retro 的形式與活動流程，刺激成員的思考，讓主題聚焦在挖掘團隊的核心問題，而不是流於表面。
架構套用
- 因為要提升 Sprint Goal 完成度 → 首先要先有機制可以知道我們每次完成了多少
- 因為要提升 Sprint Goal 完成度 → 所以要提升成員的成就感、向心力，讓成員覺得自己做的事情有意義
- 因為要提升 Sprint Goal 完成度 → 所以要透過有效果的 Retro 來不斷改善團隊的運作
# 怎麼制定 Daily Scrum 的形式？
我觀察到的現況
- 會想要改善 Daily Scrum，是因為有多數成員都在讀書會上提到，覺得目前的站立會議過於流水帳，常常會抓不到重點。
- 有時候部分成員已經完成這個 Sprint 的任務時，他便只能把一些庶務、會議或非團隊相關的事項拿出來說。
問題
- 由於每天的站立中，哪些任務會被提及，取決於負責人有沒有向大家說明，所以大家在站立中是無法得知所有任務的確切進度的。
- 當大家對於任務推進沒有具體感受時，很可能就會缺乏目標感，並漸漸淡忘 Sprint Goal 的存在。
改善方式
- 為了讓大家每天都可以知道所有任務的進度，哪些被擱置，哪些已經被完成等...報告的順序由任務排序取代人員排序。
- 與團隊成員討論站立的報告重點與句型。
架構套用
- 因為要提升 Sprint Goal 完成度 → 所以要可以讓大家清楚知道每天的目標進度，提升目標感
- 因為要提升 Sprint Goal 完成度 → 有效果的站立報告才能讓成員提前發現困難並解決，否則將降低完成度
以上就是三個我實際有作出改善的例子，目前團隊跑起來也算順暢，成員也有給出很好的回饋。不過就像我前面領悟到的一樣，團隊的狀況、產品的發展、成員的變動等等都有可能會使原本可行的流程變得過時，所以 Scrum Master 的職責就是不斷為了維護團隊的終極目標而對這些流程與規範進行調整。
也因此，我的改善方案未必能為直接的幫助所有讀者，我只能分享解決問題的方式讓各位參考，實際還是要針對你的團隊狀況，並與你的團隊成員討論，找出最符合你們的方案。
心得感想
最後，想透過幾個問答來總結這幾個月的心得，也算是回答過去自己的一些疑問。
認為擔任 ScrumMaster 有什麼好處或心得？
可以透過不同角度參與產品是很好的經驗，會有很多新的學習機會。且可以順勢改善一些流程來幫助工程方面的作業。
有沒有遵循或採用 Scrum 有差別嗎？
是有差別的，差別並不是工作內容，而是怎麼看待目前的工作內容背後的意義。每個成員都可以參與動態調整團隊所需的開發或行政流程，而非被動接收指令。
對於之後也想要 SM 的人有什麼建議？
學習與未解之題相處。你需要不斷發現隱藏的問題、引導成員說出問題、嘗試與成員一起解決問題，然後再次發現更多問題。