Scrum Master 的職責 - 引領團隊的流程，進而得以交付成功的產品。

網路上其實有不少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

來場共創型的 refinement workshop

今日來談談 TenMax Refinement Workshop 在台北RD團隊施行的第一次執行與一些觀察心得分享

基礎上，我比較喜歡稱之為 refinement workshop，而不稱之為 refinement meeting。主要的理由是，我希望團隊是透過這個 "workshop" 一起去進行 story clarification (需求澄清)，並且最後可以有一個 common understanding (共同理解)。

也為了讓這個 refinement workshop 可以更有效的被舉行，達到 "share common understanding" ，上周的 sprint retrospective meeting 後，用一個小時的時間，先跟大家過了一下主題：refinement workshop 到底目的跟產出物會有哪些，先有一個大框架的理解，才不致於讓 refinement 變了調(台語俗稱的: 走鐘)，或大家覺得白白浪費時間。

步驟上大致是：

1. 先解釋一下，為什麼 scrum 後來會去追加定義 refinement 這個活動的誕生。 

以 Vision -> EPIC 或 Features -> User Story -> Tasks -> Potentially Shippable Product Increment 的整個產品  從 概念願景 至 軟體交付 的生命周期過程，以及相關的 scrum meeting 的 artifacts 有哪些，並在 whole product life 講述 refinement workshop 的定位是什麼，要產出的是什麼，互動過程如何。  

2. 針對 refinement workshop 會產生的 artifacts. ownership. attendees. goals 跟大家解釋一下各自會有哪些重點：
Artifacts部份我這次挑了一些我覺得比較需要溝通及強調的項目：
描述、技術可行性、驗收條件(AC)、粗估算、相依性、障礙狀態、優先序、如何展示。
Artifacts的相關Ownership也跟大家過一次。(所有artifacts都可以共創，但需要釐清的是這個項目是哪個角色的call) 

3. 可能的誤區會有哪些. (先打些預防針或預告需注意的事項)
舉辦時間的選擇、議而不決、沒有共同理解、只想追求制式DoR、交付內容與決議有嚴重落差。

圖1. 溝通時候使用的畫布及其最終的產出

---

本周實際上執行時，總結一下觀察到的幾個點:

Bad smell:

• 會前、會始的議程溝通待改善，這比較屬於有效開會的障礙掃出，簡單來說是 預期 與實際 schedule 不符，這屬於開會前沒有事先進行會議障礙的掃除確認。(好吧，我被抱怨沒有專職的Scrum Master來掃除這類型的障礙很久了)

• Facilitator中離去面試沒有全程參與(沒辦法，難找出時間) 。 

• 時間關係，驗收條件 未能有討論，產出幾近於 0。(目前活在每個人的心中，鐵定認知會不同) 

• end-to-end 的部份一開始未破題。雖然這是個流程上的選擇，因為 end-to-end 一開始就講明，團隊成員可能會缺了點共創感、或對設計的What(Why/How/What三元素)會有定錨效應。故，端看workshop期待的過程與產出為何。 

• 粗估算的部份比較有價值上的爭議，不過第一次進行，這點大家對其價值性較不理解或無共識是個人覺得是正常現象。

Good smell:

• 因共創型態的關係，請大家用 3m post-it 來進行 features -> stories 的產出，似乎有達到預熱效果(那時正好是我去面試的時間，所以我只能推測) 

• 帶了Time Timer來協助做 time-boxing，感覺還是有達到一定的效率效果。 

• 事前先與大家溝通過一次，且把掛布拉到現場當reminder的效果還不錯，可以隨時回顧是否漏了什麼，以及是否schedule上有很大的延遲。會議結束，效果達成後就讓掛布功成身退了。 

• How-to-demo 的產出物，大家分工共創、下筆、繪圖，成果比很有視覺化的傳達力。使PO來確認內容的互動所需時間縮短很多。(這些都工程師畫出來的喲) 

• 優先序 及 因應粗估算所進行的 Features 取捨或 Scope Change 有被較充足的被討論。大家對於整體 end-to-end 要做到什麼程度感覺有不錯的理解 (但最後成果還是得看後續 sprint planning 、實作時的互動、交付軟體 來確認是否為真)

圖2. 共同討論並釐清細節與優先序

圖3. 工程師們共創的 How to Demo 整個流程

---

本篇文末我則想多著墨一下可能造成 refinement workshop 價值減損的幾個誤區。


1. 舉辦時間的選擇
共創時間的refinement最好是大家能有連續時間、專注當下去進行，否則時間會拖的很長而且很沒效益。與 sprint planning 之間的時間也是需要注意的點，提前太多或沒有舉行都會有相應的議題需處理。

2. 未形成最終的共識(俗稱的 "議而不決"), 沒達到 share common understanding 的用意。或未能對DoR的重點項目有一定程度的討論與共識。

3. 太拘泥於Definition of Ready (DoR) 而讓執行結果變成 mini waterfall.

這部份可參考 Ruddy 老師的 Blog:
Ruddy Lee 分享空間 Emergent Design 演化設計 Definition of Ready: 工程師要學會如何講好故事 

搞笑談軟工：
Definition of Ready—可以開工了嗎？

這部份成員也有提出來對於 怎樣才叫做 mini waterfall 的一些疑問。而我最後給的建議是，以及在 TenMax 中我希望的原則：

如果有些大家覺得缺漏的地方，但大家的心態上卻開始浮現「這應該是誰的責任、誰應該在某個meeting前或開工前就去補齊這些資訊啊」，卻不認為要嘗試在當下大家一起討論去補齊去詢問，那整個執行方向上就已經有往 mini waterfall 的方向上在傾斜了。

4. 未盡到 澄清/釐清 (clarification) 的目的，只想追求產出制式 DoR。簡言之，制式 DoR 是死的，大家能達到 share common understanding 才是真正的價值。

5. 做出來的東西與 refinement 的 common understanding 不相符。或對交付物進行變更未與相關權責人員討論。