前言
在 Facebook Scrum Community 社團中，Odd-e Taiwan 同事 David （是的，柯仁傑, 敏捷三叔公，現在是我 Odd-e Taiwan 的同事唷）拋出了一個議題：「大家覺得 Scrum Master 要懂技術嗎？」當然，這邊「懂」的定義，每個人心裡都不同，所以要先說清楚「懂」是什麼。
而 Odd-e 香港同事 Steven 在回覆討論串貼上了 Odd-e founder Bas 在 LeSS 上的一篇文：The Scrum Master as a Technical Coach，這篇文點出了我們在台灣看到大部分 scrum master 對團隊的幫助所欠缺的短板能力。
這也讓我不禁回想起，我身為一個技術職能的工程師，在一開始是如何以 Scrum 來進行軟體產品開發的。
Agile 與 Scrum 對我來說是不一樣範圍的東西，身為開發人員，我在職涯剛開始時就奠定極限編程（Extreme Programming, XP） 的基礎，但 scrum 的團隊協作方式，是在職涯約 6-7 年之後才開始的
我在 Scrum Team 裡面的工作
回想起來，只能說自己的經歷真的算是誤打誤撞，幸運地走出了還蠻上軌道的路。
我過去是個 team leader, 也是團隊中的 tech lead, 但在 Scrum 轉型時期，我是一個預設不領 task 的 lead。（對，我們一開始連 Scrum Master 這樣的角色都沒有，但其實我現在回想，我其實大部份的工作內容都是 Scrum Master 的守備範圍。但一開始缺少引導/教練 的相關技能）
我的主要工作，是跟團隊一起 pair, 從 pair 的過程中把產品品質做好，把團隊技能拉起來，把基礎建設跟團隊規範持續改善，pair 過的就節省 code review 的時間。
當然，單元測試、code review、持續整合 with build server、自動部署、重構，產品共享，甚至是 TDD，這些在我們進行 scrum 之前，該有的基礎、規範、技能，都已經有一定程度了。（因為我在 scrum 之前負責的工作，仍然包含把 XP 相關的實踐引入產品開發流程中）
除了 pair 以外，scrum 初期我還會跟團隊中一位專業的 QA 一起與 PO 進行一場小小的 pre-refinement, 從需求、開發、測試三個維度來看，需求是否已經到 ready 的程度，避免整個 team 在 refinement 會議時間過長、效益過低，並且提前抓出技術可行性、產品功能設計的盲點，以及商業價值評估。
除此之外，我稍微盤點了一下，我還有其他 5 個機動性的任務：
- 幫助 PO 跟 stakeholder 的交流：當需要我時，我會站在技術端的角色，協助 PO 一起去跟 stakeholders 說明，或是爭取時間、資源，或是跨 team 的協調工作。我也能第一手獲得從 stakeholder 那邊來的資訊、重點、限制和期待。
- 監控線上營運與 bug 分析：我會幫忙觀察線上營運狀態，bug 的類型，緊急程度跟影響範圍。從 bug 的部分往往可以分析出來我們流程還有哪些地方可以改善的。如果是緊急程度最高的 bug, 而其他人正在忙，我會跳下去處理，讓影響範圍降到最低。
- 用來應付重要且緊急插件的機動戰力：如果 PO 或部門臨時有什麼插件需求，我就是一顆很好用的活棋，我可以從 pair 過程抽出身來，幫他處理這些插件，以解燃眉之急。
- 架構、決策、跨部門協作、基礎建設、技術研究：系統架構面的設計，整個部門技術選擇的決策，跟各個專案 kickoff 的 reviewer，跨部門團隊合作（例如安全、資料部門、search），推進部門與產品的基礎建設、自動測試、流程開發規範、技術前沿研究、技術教育訓練，也是我在團隊內外的職責。
- 讓工作流更順暢，尤其是 PO 身上的工作負擔：因為我們的 PO 當時還算是要兼任 help desk，我們出現過零星幾次，團隊功能做完了，但 PO 還在忙，瓶頸出現在 PO 身上，因為她被線上的營運問題搞得喘不過氣。
當時我們團隊當時把手上的工作都先暫停，然後跟 PO 盤點一下她現在手上除了放到我們 product backlog 的部分，還有多少事情得要處理，分析有哪一些是會重複發生的。
後來我們針對會重複發生的，要定時觀測的，寫了幾隻報表，設定好 cron job 週期，固定週期就會撈資料寄給 PO, 然後一些快速修正資料的，寫好程式讓她下次處理有介面可以用，而且其他人也可以迅速透過介面幫她處理。
關於 bug/issue 我們的作法
關於 bug 或線上異常的處理，在台灣 Scrum 剛開始盛行前幾年蠻多人問的，但最近幾年比較少見。這邊也分享一下我們當時的作法。
我們的 bug (issue/ticket) 是會排入 product backlog 的。或許是我們的 bug 大部分都會經過 PO, QA 而來，對 PO 來說，她能判斷 bug 的緊急程度，與現在正在進行的 sprint backlog item 何者重要。（別忘了還有我這顆活棋可用）
如果真的就是要當插件進來，我們也會一起討論跟決定，最後還沒領的 item 是否該排出 sprint 挪到下個 sprint 做。
如果大家都認同該插件的必要程度，以及 sprint items 全都不能 miss 在這次是很有意義的，我們就會討論作法的調整（技術債換時間的可能性），或是透過加班，考量多點時間消化掉插件的可行性。
喔，對了，我們的 PO 跟 RD 職級是平行的，我們就是一個團隊，大家負責自己的角色職責、互相 cover、互相學習，榮辱共享。所以沒什麼「壓迫強逼」的問題，一切事情都可以團隊一起商量出來。（當然，我們團隊每個人對產品的 ownership 都很強，就是有問題都會主動跳出來關心發生什麼事，可以怎麼解決那種）
而且我們沒有專屬的 support 團隊或是角色，我們會排 on-call 的情況，只有農曆過年這種大家可能大部分都出國，手機/網路可能連不上的那種，才需要確保每天都有人可以處理。（這段就是考驗大家的 ownership 了）
關於線上異常處理
順帶一提，對於線上營運跟 bug 的處理，我們能有如此餘裕，也是因為我們對於 production 發生的 exception 基礎建設投入了不少心力。
我們可以每段時間檢查線上出了哪些新型態的 exception，統計該時段該 exception 的發生次數以及拋出 exception 的來源。並且跟上個時段，或是上週同一時段（電商通常會以上週同一時間來當作對比，因為對比樣本會更具備代表性）的差異。
超過了限定的 criteria，系統就會發通知給大家。所以一般在剛上線之後，每個人都會盯著系統定時送出的線上異常報表，以及系統警告通知。
對我來說，身為產品的開發團隊或 owner（不是指 PO，而是絕對的 ownership），我們對線上的營運狀況、異常處理的目標是：當線上出現問題，客戶、使用者或相關 stakeholder 用任何形式通知我們的時候，我們可以答出這樣的回覆：
感謝你的問題回報，我們在「xx:xx」時已經第一時間發現了問題，影響範圍大約是「xxxx」，我們預計在「oo:oo」將問題排除，初步判定可能原因為「xxxxxxx」。
當團隊外的使用者碰到了問題，在他們還沒回報產品團隊前，我們就先掌握了線上的相關資訊，並安排人員進行問題分析、影響範圍分析、準備對應的解決方案，這會讓團隊對外的 credit 非常好。客戶一般能理解系統難免會有 bug，他們會發怒的原因通常是因為團隊後知後覺，甚至是不知不覺。
當每次我們都能第一時間掌握線上異常的先機，這對做 7×24 小時服務的產品，非常非常重要，也是許多公司忽略的基礎建設的一環。
結語
回想起來我真的挺幸運的，誤打誤撞走出 technical coach 這條職涯路線。後來再接觸了更多引導相關、Lean、LeSS 之後，就更能擔任 agile coach 的角色。而 Odd-e 裡面的大部分同事，再加入 Odd-e 之前的經歷，其實也都蠻像的，只是各角色的比重不同而已。
最後補上我對於原討論串內容的觀點：
Scrum Master 就是幫助整個團隊（scrum master 對我來說，也可以換頂帽子變成團隊的一員）持續改善、成長。
如果團隊的瓶頸點在技術面，那 scrum master 如果要能讓團隊突破瓶頸，他就得懂「團隊現在技術面少了什麼東西」，如果團隊不懂那個東西是什麼，scrum master 就要想辦法讓團隊懂那個東西是什麼。（辦法可以有很多種）
大部分的改善都止步於團隊「不知道自己不知道什麼」，而 scrum master 對產品開發過程中團隊所需要的東西，至少都要到「知道」的程度，再稱職一點，應該要到能「輔導」、「協助」、「共同進行」的程度。再專業一點，就是要能夠「指導」、「示範」、「以身作則」。
所以後來 林明洋 在回覆討論串中，補上了另一位 極限編程 大師 Ron Jefferies（軟件開發本質論 的作者，如果你沒看過，一定要買來看一下，比起一堆 agile/scrum 的書，都來得更實務、核心、精準描述本質一點）的一則 twitter：
Let’s have a new rule: you don’t get to say what agile software development is, or say how to do it, if you cannot personally develop software as part of a team, in the agile style.
Ron Jefferies
是的，因為我做得到，所以我也是很認同這條新 rule 的：
如果你自己沒法在團隊中以那種敏捷方式來開發軟體，那就不要出張嘴告訴大家，敏捷開發是什麼，或是敏捷開發該怎麼做。
我們很常提到的兩句話：
- Show, don’t tell.
- Talk is cheap, show me the code.
以身作則的示範，甚至 pair，才是讓團隊了解的最佳方式。