接著昨天分享的話題，針對成為 Scrum Master 的經歷與想法再進行補充。
大家從標題「更基本的部分」可能也發覺了，這些文章我刻意倒過來寫，從最直觀可見的，寫回一些需要觀察與體會的部分，也許這樣會更容易掌握。
先從《The Great ScrumMaster中文版: #ScrumMasterWay》這本書說起，初次看可以建構一些基本概念，而後隨著自己的實際行動，反覆回看書本進行對照，會有不錯的帶入感，除了審視目前的還缺了點什麼，也可以看看 Scrum Master 之路有了哪些成長。
在書中可以看到關於 Scrum Master 的許多面向，涵蓋了基本概念、心態、成長路徑、團隊經營、變革、工具與技能等，而書名後面的「#ScrumMasterWay」也是本書的重點，以三個層次來總結 Scrum Master 與團隊的成長過程，作為進步的指引。此外，第 7 章 ScrumMaster 的工具箱，提到以下的主題，都相當實用，在此作為關鍵字將其引出，方便讀者再從中探尋其他新知，而細節就不再重述。
掌握守、破、離
系統規則
正面想法
引導
教練法
根本原因分析法 (Root-Cause Analysis)
影響地圖
Scrum 的大規模化
成為 Scrum Master，閱讀這本書是個不錯的開始，也推薦團隊任何一員閱讀它。這本書雖然輕薄，但裡面總結了不少東西，我若跟著提一次意義不大，因此接下來我想分享我的觀察，從「源頭」開始說起。
Scrum 設計精巧，看著那不長的 Scrum Guide 一閃即過，也許沒有產生太多的體會，我們很容易直接去執行各個活動，將人員套入劃分好的角色，這一方面也是社群有充足的資源可以參考，也不時會有各種新方法的分享，Scrum Master 或團隊若想嘗試都是好事、都是行動力的展現，但是團隊本身擁有多少的基本功，對於更底層的源頭有多大認識，反而是容易被忽略的。
所謂更原始的層面，例如：團隊溝通、團隊當責、時間掌控、主動學習、不放棄的精神。
夠原始了嗎？不！再往前到「人」，一群「人」每天穿梭在團隊當中，與自己合作著，但又有一群人是不是被忽視了？特別是我們都專注在所謂 Scrum 的活動上。誰呢？－－「利害關係人」(Stakeholder)。
利害關係人的範圍很大，端看我們站在哪個角度來看它。我們每天會與團隊成員接觸，卻不一定與客戶、老闆、其他部門的成員接觸，他們可能在特定會議出現，但在第一時間團隊是否就識別了他們的願望？以及後續的行事是否有持續考慮到他們？不光說工作生涯，就在求學階段也常常看到利害關係人被忽略，他們偏偏又是成事的關鍵。
有些值得反思的問題，團隊或我們自己，對於利害關係人有多了解呢？他們真正想要的是什麼？他們與我們的何時交流？我們又是如何與他們交流？我們要交付的價值確切來說是誰的價值？這些，在還沒有執行 Scrum 之前就很重要，倘若之前沒有到位，跑了 Scrum 應該會有被重擊的感覺，體會到原來一直都有落差存在，過去卻這樣看也不看的衝過去。不過我們也不用怪任何人，畢竟各種活動、方法論實在是太引人注目了，一不小心就會一直追求，想要把新的方法不斷帶進來，可惜卻一直沒有掌握到更基礎的關鍵。
當然了，身為軟體團隊，專業技能也是基本功，也是想要有所成果需要回頭審視的源頭，好不容易知道客戶真正想要什麼，但礙於技術上限無法達成，又是另一種可惜了。
我在前面的文章「Scrum 也自然嗎」也提到過，大家可能對 Scrum 抱有期望，以為導入後自然會變好，卻常常忽略了導入前早就存在的問題，而在 Scrum 幫我們暴露問題之後，我們的下一步又是什麼呢？
作為引導團隊的 Scrum Master，時刻回首到更基礎、更貼近來源的議題上，也把這個「很小的」大觀念帶給團隊，免得白忙一場。
從鐵人賽第一天到現在，裡面含有相當多需要學習的部份，如果我們把視野擴大，看向整個鐵人賽，又有數不清的知識點與學習路徑。
Scrum Master 的工作內容是如此多面，從各點展開也有非常多的主題，這需要積極的自主學習能力。好在，現在的學習資源相當豐富，也早已突破許多時間與空間上的障礙。我同時鼓勵 Scrum Master 掌握(了解)部分團隊技能，以軟體團隊而言，可能是團隊使用的程式語言、框架、架構，以及相關的領域知識，如此我們更能以相同的語言與團隊溝通。
然後，你就會學不完了 (喂)。
這個議題在《The Great ScrumMaster中文版 #ScrumMasterWay》一書也有所探討，描述了 Scrum Master 兼任團隊成員、兼任 PO、兼任主管與跨多團隊服務的 Scrum Master。很自然的，沒有絕對好壞，書中確實給出每一種組合的優缺點與其結果，最終僅推薦 Scrum Master 同時支援兩到三個團隊的方案。
視組織規模，有時發生兼任的情況是難以避免的。這種兼任帶來的身分重疊確實會有一些困擾，一個直觀的例子是，帶有主管身分的 Scrum Master 可能成為團隊成員無法暢欲所言的原因，更不樂見的是，也許主管本身就是阻礙。但同時這也會帶來一些機會，擁有管理權限的主管，會更有力道推動變革，也可以直接調動資源，給予團隊更快更實際的支援。
多重身分是一種取捨，以管理手段介入也可能引發更大的反彈，產生一種武斷的感覺，而主管能否傾聽團隊本身就是管理與領導上的要事，不應該等到兼任 Scrum Master 才來考慮，這麼說來，又是一件發生在 Scrum 之前的「基礎」呢。
所以說多重身分是好是壞？很難說，若現況需要兼任，先把它當作一種機會，只是記得背後都有取捨，假若在過程中我們確實發現到問題，那麼專任的 Scrum Master 就應該出現在團隊發展的道路上。
任何事要做好都不容易，與全天下的 Scrum Master 們說聲謝謝！
iThome鐵人賽
看影片追技術