網路上其實有不少Agile文獻可以參考，去理解Scrum Master這個角色。不過在進一步解說之前，也要先一併理解一下其他Scrum的基礎關鍵角色與權責為何。以目前我個人對於Agile Scrum的經驗與見解，Scrum的基礎關鍵角色與其權責，其核心職責目標可以用下列的三句話來歸結:
Product Owner: Makes Product Success (讓產品得以成功) (註1)
Scrum Master: Makes Process Success (讓流程得以成功) (註1)
Scrum Team: Makes Deliverables Success (讓交付得以成功)
以「讓流程得以成功 (Makes Process Success)」為出發點，就很容易去理解Scrum Master這個角色的職掌與技能需求了。因此，讓團隊的工作流程得以順暢，交付一個成功的產品，是Scrum Master最核心的工作職責。
以敏捷思維進行開發，其實不能說是趕流行，其發源早於的 .com 第一波網路泡沫化之前，但論及其真正開始熱絡起來的主要原由，私以為則應該是 .com 網路投資泡沫化後，這些眾多的失敗以及成功的經驗，而讓敏捷的思維快速地開始發展起來，為的就是解決 internet 時代的高度競爭、高度變化，而產生 快速驗證與交付 的需求。
假設大家想要做的生意，是屬於 Internet 相關的產業，那麼，市場與投資者對於 快速驗證及交付 的需求 是研發團隊無法閃躲的議題，而這樣的團隊則需要更具有 研發能量與創新 (Energy & Innovation)，可以說完全無法以 以往的 說一動做一動(Command & Control) 的方式來進行。
敏捷所期望的是團隊能夠有足夠的能量，以自我組織的方式去達到快速驗證及交付的目的，加上目前世代所表現出的創造力，讓他們擁有事情的擁有權(Ownership)並且以互信(Trust)為基礎的流程。
我個人還蠻認同 敏捷文化 (註2) 一書之中所提到的 Trust 與 Ownership 兩種維度來進行敏捷文化的引導：「信任」與「擁有權」。而理想上，Scrum Master的角色就是同時要在團隊之中 以及與利害關係人(stakeholder) 之間建立 互信 並且 盡可能 權責清楚。
國內大多數的團隊，可能都處於 Command & Control 的模式，因此，轉型是不可免的，但想要從 說一動做一動 的工作模式，轉變為 具能量與創新的自我組織模式，並不是一件容易的事。因此，多數團隊其實是處於需要敏捷轉型的狀態，而 Scrum Master 的角色就是想辦法讓這個轉型變得成功。
但敏捷轉型是有可能面對 失敗 與 衝突 的，
(1) 過度的信任與放權，但團隊並沒有那個能力與意願去承擔權責，下場就是以失敗收場。如，下圖中的黑色區塊。
(2) 放權但又脫離不了微管理(Micro-Management)思維，則會導致眾多的衝突發生。如，下圖中的紅色區塊。
附圖1 . The Agile Culture 中以 Trust / Ownership 兩個維度的模型來闡述什麼樣的特質可以促成交付成功的產品或商業價值。
Scrum Master就是窮其辦法，讓團隊與相關利害關係人，可以在一個擁有互信基礎的狀況，讓團隊可以自己扛起權責，讓團隊保持在具有創新改善的高能量狀態，進而交付出成功的產品，
這也會是我「傾向」支持會需要有一個 full-time scrum master 的專職角度的主要原因，因為要引領這樣的轉型，所需要花費的心力不是那麼的單純只是一些工具及流程的導入，而是整個心態心法的轉變，工具的導入可以在主管及老闆的一聲令下就執行，但怎麼樣導入的有效果、可以長久，不會使得大家表面照做私下卻議論紛紛，這時是需要有人可以跟著團隊一起去體驗、觀察並提供反饋，這時就是一個可以長時間跟團隊相處的 scrum master 可以去著力的地方了。
非常推薦大家閱讀一下 延伸閱讀 註1 的 Blog，作者很有系統地呈現了Product Owners 及 Scrum Master 的 360 度關係人以及會需要做哪些事。
以下則是說說我自身的故事：
這也跟最近同仁在 facebook 上所發起的一篇分享有關「Scrum 團隊中是否一定要有 Scrum Master?」。於是，我想了想，把這篇其實二年半前就已經存為草稿的文章，最後公開並補上了下面這段跟大家分享。
要真說我接觸 Agile Scrum 的九年以來，自己其實多數的時間也都是 Team Leader / Managers 身兼 Scrum Master 居多，唯一比較算是卸下多重角色的時間，大概是我投入在 Project GATE (現名為 BeanGo! 的 Mobile App) 的 2013年-2015年初之間的這段時間。
但嚴格說來，我也不會稱之我這段時間是個 full-time scrum master，而比較像是個 agile coach。因為這段時間，初始成員多數都是跟著我的團隊已經 3-5 年的成員了，Unit Testing /Integration Test、Version Control、CI/CD、Scrum 活動這些基礎知識及實踐早就已經再熟悉不過，技術團隊的成員都能自主的打理這些事情，所以我這2~3年的重點改為在延伸 Scrum 的框架的一些延伸活動的實踐，像是 Refinement、Agile Hiring、Eat your own dog food、BDD/ATDD、Stakeholder Vision->Backlogs的溝通管理、Vision-> Potentially Shippable Product Increments 的生命流程打理.... 以及 "也許"對大多數團隊成員而言最有感的價值是：對於一些流程作法有爭議的時候，出來當一個仲裁者。這一類的事務。
所以，說真的，團隊是否需要有 full-time scrum master/agile coach，以及其所能發揮的價值，其實是端看團隊的現狀。當 基礎的工程 已經深植在團隊，新人的加入自然就靠團隊本身已建立起來的 Convention 新成員就會學會、或在做中學去跟隨，團隊成員彼此就可以自然在協作之間發生而融入團隊的節奏。而敏捷心態的資深人員自己會再去鑽研，並將相關的所學回饋到團隊中去提昇團隊一些更深化的工程實踐。
這時 scrum master / agile coach 可以不用去專注於導入這類的事，讓團隊的工程人員去發揮。要讓團隊運作的更順暢，其他可以做的事情還是很多，這時 scrum master / coach 可以針對團隊"流程"順暢效果有顯著效果的地方著力，甚至開始解決團隊間之間問題，讓跨團隊的運作可以更順暢。
至於 Scrum Master 的日常是什麼樣子，可以參照我的另一篇 Blog - Scrum Master 的日常 - 以 Project GATE 為例 以及其中的延伸閱讀。
而現在所處的團隊 TenMax 又是怎樣的一個故事呢，就讓我先欠著吧，機緣到了自然會跟大家分享。
----
延伸閱讀
註1: Every Great Product Owner Needs a Great ScrumMaster
http://www.romanpichler.com/blog/every-great-product-owner-needs-great-scrummaster/
註2: The Agile Culture - Leading through Trust and Ownership
http://www.amazon.com/The-Agile-Culture-Leading-Ownership/dp/0321940148
Is the ScrumMaster a Full Time Role? Yes, According to the ScrumMaster Manifesto
http://www.infoq.com/news/2012/01/scrum-master-full-time-role
Scrum Master 的日常 - 以 Project GATE 為例
http://r-hsiao.blogspot.tw/2015/03/scrum-master-project-gate.html
沒有留言:
張貼留言