昨天結束了 Jackson 與 Philip 老師兩天的 「Scrum Master 領導力」課程，對於 Scrum Master 這個角色又有了更深一層的體悟。記錄一下自己的感想，也供日後自己能夠不斷的回顧、省思。
若要我為這個課程下一個總結，我會說：「以終為始」。
不知道有多少次，我們都會詢問「該怎麼讓團隊敏捷起來」、「該怎麼樣讓團隊達到自組織」、...等，而往往都忽略了背後的所要解決的「問題」。敏捷並不是萬靈丹，在確立問題之前，似乎已經為團隊抓好了一帖「靈丹妙藥」。諷刺的是，這個狀況在 Scrum Master 身上尤其常見。當身上握著 Scrum MASTER 的這把鎚子，看什麼都想敏捷它！這也難怪這麼多人正在被敏捷開發著、遭受著「敏捷」的荼毒。
身為 Scrum Master，當自己看到一個「問題」的時候，是否曾經思考過這真的是「問題」嗎？會不會是自己的誤判？更進一步來說，這個問題，是你覺得的問題，還是團隊覺得的問題？若是自以為的問題，常常為了「提早預防」，要求團隊「幫你」解決，Then？你是你，團隊仍是團隊，這樣有助於團隊更加「敏捷」嗎？然而這種情況，往往發生在團隊不「遵守」各種 「Scrum 規章」、「標準」規範（ex：寫程式不寫測試）的狀況下。當一個 Scrum Master 越是資深，就更容易落入這樣的坑裡，與自己認知的不同，都是錯的。
在這樣的主觀意識很強的思維模式下，更像是一枚 Scrum LEADER / MANAGER，為團隊做決定、預見風險、提早排除問題，甚至是安排進度。看是利益良善的經營，卻剝奪了團隊擦傷、學習的權利。
或許 Scrum Master 是個精通 Scrum 的角色，但並不是如同「顧問」般的存在。不應該用自己的視界嘗試去定義及預見團隊的問題，甚至魯莽地直接插手要求改善。更應該做的是引導團隊去發現並解決他們認為的問題。更甚者，在團隊需要協助的時候，具有相對應的能力給予支持。
與其說是培養 Scrum Master 的能力，更不如說是培養看透問題本質的思維方式。我會用「抽離」兩個字來詮釋這樣的模式，從團隊中抽離自己成為一個客觀的觀察著；從關注團隊內容抽離至流程甚至是組織、文化的高度；從互動要素中抽離出感知資料層面的訊息。這都不是短時間內可以達到的高度，要走得路還長的很～。
身為一枚 Scrum Master，把自己作到失業就成功了呢！！
