GA4

2017年7月10日 星期一

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

2017年7月5日 星期三

來場共創型的 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 不相符。或對交付物進行變更未與相關權責人員討論。






2017年5月5日 星期五

一場略為不同的 職場成年人的讀書會 之旅


這次 TenMax 讀書會第二輪由我推薦及拉票的"平台經濟模式"中選,這次的讀書會導入了幾個 "職場成年人規則"

讀書會目標:
* 以這書當做框架,大家以有系統性的方式討論TenMax相對應的議題,以能深度討論為終極目標
* 以職場成年人的方式來參與讀書會

現階段這本書的讀書會已結束,也藉機整理一下整個執行的過程及群體的心得,

如果先破梗講一下總結的話,引入職場成年人的規則,算是有發揮預期的效果:
(自律)(尊重)(透明)(有投入才會有收獲)(自由表述)(分享意見)(整合意見)
事實上這與敏捷團隊文化也有高度的關聯性,有興趣的看倌請繼續看下去。

1 - 與敏捷文化相呼應的參與規則


先從會長我設定的幾個規則的理由說起吧:

* 沒先看內容&帶著答案進來的人,會被會長請出場。 (找書上的 金句 進來並分享你為何選擇這段的理由)


這是一個比較值得深入拿出來多講一點的規則:

=> 沒有先讀過的話,討論沒辦法加速聚焦或深化。
=> 促使精實會議時間的利用,馬上切入主題。
=> 也藉此機會表達不接受撿現成速食知識的想法,必需要有投入一定程度的投入,才有資格參與討論。一方面也呼應,敏捷圈常常提到 hams-and-eggs 議題。
=> 需要去思考背後的原由,為自己的選擇探討背後的理由,可深化閱讀及思考效果。

也許有些人會覺得,讀書會也常見一種方式也算是大家分批投入某些章節,再與大家分享,其實也是一種有投入且又具分工節省時間的方法。但我是覺得書真的是要自己讀過、融匯、思考咀嚼後、整理後,才會是自己真正的養分。別人給的速成答案其實是有時會真以為自己懂了,其實沒懂,或當下雖覺得觀點不認同,但不知從何處切入詢問而無法有比較深入的討論。

* 場場 workshop。

=> 深化討論TenMax目前的產品及營運現狀。
=> 與工作內容高度相關的互動式討論,比較能深化大家對於這些內容的理解。
=> 敏捷工程文化鼓勵的是溝通並且理解所創造的價值。「想靠幾個高手做top-down規劃 ,發包/分配給單純只按規格實作的程式設計師」的碼農文化,與敏捷工程文化不符。
=> 我們這邊也鼓勵成員不要將自己定位成碼農。對自己的未來也更有幫助,也較能創造雙贏。

* 隨時可加入及離開,但需公開原由。

=> 理由: 透明原則。不得無故、隨興參與或不參與。

* 不定罰則。

=> 理由: 覺得有價值就會想排除萬難參與,無法產生價值就自行決定把時間花到別處。沒必要定些罰責來框住大家,強制出席。

* 與會者可以提建議,會長拍版。

=> 理由: 尊重Ownership的同時也不專權。會吸收大家的input,但最終有Ownership的人需拍版。

* 不認同以上規章,可以另外找新會長舉辦讀書會。

=> 理由: 尊重Ownership。

* 會長盡力維持讀書會的品質。

=> 理由: 有Onwership的人自然也需維持住大家想要的品質。扛起Accountability。

* 會長有權中止品質不夠的讀書會。

=> 理由: 當上述態無法達成的時候,讀書會所期望的目的無法達成,自然沒必要繼續舉辦下去。

2 - 執行結果的成效如何呢? (從我個人的觀察)


大致上值得論述的點有幾個:


  • 確實有些對本書有興趣的人,也買了書,但在聽完規則後,確認無法投入這麼多時間跟上進度,而選擇了不加入。說真的這也是一個成年人的表現,大家也都是平常心看待。
  • 參與的人員雖然有愈來愈少,時有脫隊跟不上的狀況而請假,但是每次的討論品質與熱絡程度依然能維持一定的檔次,不會太low。(還好,人數都還有七八個人參與,不至於人太少討論不下去或多樣性不足)
  • 有些人表示,其實有幾次會很想進來旁聽,但沒念完不好意思進來。(挺好的,有自知自律並能尊重及遵守規則)
  • 書中的論點其實每個人都有不同的見解,未必同意作者的說法,或部份內容整理略顯零亂難以看懂,討論會上有這類的聲音出現,很棒! (真的,盡信書不如無書)
  • 讓我覺得當一個讀書會會長與團隊一同討論這本書,有創造出我個人覺得這個投入是值得的(為了主持這種高互動式又要維持品質的讀書會,主持人投入的程度可遠多於其他人呢)
  • 反饋仍然不夠多,每次讀書會結束後都有在頻道上希望大家留些feedback,但每次數量愈來愈低。(自我糾結中~~~ 顯然有哪裡不太對,催不出大家的意見,但最後一次現場Retro又其實算有反饋每人至少3~4張post-it)


3 - 執行結果的成效如何呢? (團隊Retro時講出來的觀點)



Good:

  • 討論質量挺不錯,但缺乏共筆留存。未能紀錄下來分享給未參與的同仁有點可惜。
    => 其實我個人的觀感是,就像 odd-e 上海 主辦的 AHA_Moment,人生就是要留點"遺憾",才會因而想要未來多點投入或參與吧。
  • 最後大家回顧會議的整體分數算是高於一般水準的(我們採用Planning Poker 1~21 費式級數滿意度,多數人給了 13分,少數人給了8分(一般水準))
  • 聽到各式多元的意見。(幾乎每個金句分享後續都有人接著補充對於這段話從自己的觀察的想法是什麼)
  • 最沒有懸念的部份且大家覺得最有收獲的是:圍繞著TenMax主軸在討論相關的議題。


Bad:

  • 普遍讓大家最糾結的則是覺得章節閱讀速度有些跟不上。


4 - 團隊 Retro 的 Next Action (Try or Avoid)


下次可以嘗試(Try)的事情:

  • 黃金討論的紀錄與共筆
  • 提供更多不認同的聲音
  • 假設大家都讀過,直接用書裡的分析方法討論TenMax狀況
  • 讓每個章節Onwer來主持會議
  • 改時間提高參與度(找尋更好的讀書會時間點)


下次可以避免(Avoid)的事情:

  • 分心(有人常常被其他更有吸引力的書或技術吸走,而沒有跟上讀書會的章節進度)
  • 書沒看完而中斷幾次讀書會的學習交流,有些可惜。
  • 這次的規章要求大家先讀過的,可能比較適合這種軟性書籍,硬性技術書籍不合適?
  • 流於形式的K完書本。
  • 發言讓人有做結論的感覺(這張是我自己寫的,也確實有參與成員日前給我這樣的feedback,這議題對於一個VP而言是個難題)



5 - 最後總結


真要說這次為什麼特地讓自己慢下來,花時間籌畫這個形式的讀書會並且帶領大家討論:
(0) 難得有這麼一本書可以做為一個討論的框架,讓想參與的成員一起參與討論,更理解自己在做些什麼,也趁這個機會與大家交流目前 TenMax 的現狀,也看看團隊目前理解的程度到哪邊。
(1) TenMax 工程文化原本就鼓勵大家多了解商務面、生態圈的需求,做出來的產品才能較符合實際營運或商務的需求,降低返工/長尾、減少溝通成本,交付效率才能再進一步改善。
(2) 其實 TenMax 不少工程人員對整個產品生態圈的運營也是很有興趣的,透過這個機會其實可以也趁機讓大家多了解一下 TenMax 開台近二年以來的一些決策上的選擇背後的原由(或可能的原由)。

要說這次個人覺得最可惜的地方是:這次商務開發人員沒有人參與這個讀書會,整體而言,少了來自商務開發第一線人員的第一手觀點分享。但基於職場成年人法則的前題下,我也就沒有去遊說。只能說,至少仍有三名成員(包含我)有參加每周營運例會,因此我們盡可能從過去的營運例會中 執行長/商務人員 的所發出聲音中,適時適度的也在這個場合講出來讓大家理解,還在覺得可以接受的範圍。


心中OS: 終於把這篇很難下筆的讀書會心得寫完了。可以切換到下一個重點目標了。

心中OS2: 最後其實有稍稍利用 狩野分析模型 來設計並做了一下問卷調查,不過這只是自己的一個小嘗試,心得太淺,就不分享這部份的內容了。 

附錄1:最初始版本的規則(供參考用) 

讀書會形式 (執行前的公告)
Session 1: 分享心得  (20分鐘)
必須事前閱讀,並帶著以下問題的答案進來
你覺得本章節的想跟大家分享的「金句」/「印象深刻的句子」是? 理由是什麼?
你覺得本章節在講什麼?
有哪些你與書上見解不同的地方? (optional)
Session 2: Workshop (30分鐘~40分鐘不等)
以TenMax為例,這章節的一些重點對應到什麼? 有什麼議題可以探討?
Session 3: (10分鐘)
讀書會中,你收獲了什麼?
對此次讀書會內容的評分及建議。
你下一步想做什麼? (Actions)
* 沒先看內容&帶著答案進來的人,會被會長請出場。
* 場場 workshop。
* 隨時可加入及離開,但需公開原由。
* 不定罰則。
* 與會者可以提建議,會長拍版。
* 不認同以上規章,可以另外找新會長舉辦讀書會。

附錄2:會長在讀書會前的先提出一些問題的案例:

Workshop Question  (思考問題)
廣告系統的核心互動是什麼? (Chap 3)
TenMax的價值單位是什麼? 篩選機制是什麼?
廣告系統中: 有價值的交流是什麼? 無價值的交流有哪些?
Question:
為什麼TenMax都保證Clicks數投遞了。客戶還一直在意CTR?
廣告系統的核心互動是什麼? (Chap 5)
Question:
使用者投入程度及活躍使用程度比獲取用戶更為重要
以TenMax(或數位廣告)而言,哪些事件是 使用者投入程度增加的指標?
TenMax曾經做過哪些事情,是促成使用者投入程度有關的?
以下策略各是什麼,TenMax 是否有用過類似的策略?
跟兔
搭便車
播種
招牌
單邊
傳教士
大爆炸
微型市場 

2017年3月30日 星期四

插單看板可視化的誕生 ( 實體看板的再度邂逅系列 - 2 )


插單處理一直是在線營運的產品必定會發生的活動(Activities)。研發人員不喜歡插單,特別是以Scrum框架來run的團隊,不僅僅是帶來的是Context Switch的嚴重影響,並且也與Scrum Guideline嚴重抵觸,很大程度會影響團隊是否有辦法達到允諾的Sprint目標。因此,插單一直是個在跑Scrum框架的團隊中很具爭議性的議題,甚至常常有團隊自己得到的結論就是:Scrum不適合營運中的產品開發。這話題,大家話匣子一開一定是講不完,火力四射。

看板可視化誕生的原由:
延續上個 Sprint 的 Retrospective 項目(實體看板的再度邂逅系列 - Part 1 ),資深成員提出來,Sprint Fail有很大一個因素是插單太多,所以提議團隊新增一個看板,來將插單(Interrupt tasks)可視化呈現。

本文的重點也就針對這個 插單看板的演化過程及Retrospective的討論過程跟大家做個分享。




其演化過程如下:

1. 一開始只有 Sprint 中每日的滑水道 (依每日發生時間貼上)
2. 有插單要處理時,Daily Scrum討論到,開始需要處理時,
壓上負責的 Owner,最後覺得要有個 Reviewer,故又決定壓上 Reporter/Reviewer
3. 處理完 Mark 上 DONE 字樣。最後覺得有點項目混在一起,故開始把處理完的集中到滑水道的右邊。
4. 有討論是否需紀錄時間,但不強制。 
本Sprint 仍盡可能 每日 Daily Scrum 後大家聚在白板前反思及討論 

Sprint結尾,殘酷的事實顯示是這樣的:



( 上圖 - 本次的 "插單看板" 於 Retro 當日的狀態,天天都有插單,天天都在處理插單 )


( 上圖 - 本次Sprint的於 Review當天的看板狀態 )





就帳面上看來的事實有:

本Sprint有被登記下來的的插單共 27個 Items
本Sprint依然是Fail,留下 3個 Todo、4個In Progress、3個Ready to Verify。(原先Planning結束時是覺得略有留下些微的buffer時數)

經過上個Sprint大家對於 Sprint Success/Fail的認知同步後,大家對於Sprint Fail的狀態比較能坦然面對。但也因為有這些數據依據,這次其實大家都有心理準備要來討論更深一層次的問題了,為什麼狀態是這樣? 看板盤面背後的意函是什麼?


團隊依序較深入的討論了幾個插單看板的議題,並且有很明確的數字可以佐證討論:

議題1. 有沒有跟PO討論過?

全部的插單 27,其中10個有跟PO討論過(有討論做與不做/優先序):
PO確認率 10/27 = 37%

插單中,有完成的 17個,其中5個有跟PO討論過:
PO確認率 5/17 = 29%

bad smell: PO/SM不是應該當防火牆的嗎? 怎麼有這麼多直接跳過了呢?
肇因: 本團隊大家都是接了單就開工了。很大一部份是,因為TenMax產品在營運中,營運中所接受到的議題是不太有緩衝空間,都得第一時間釐清問題。故,本團隊很常發生BD就直接把問題反應到 Slack 上,然後 Run Sprint中的 RD 成員自己就接單了先去排除去了。雖然去年後半年有成立產品營運支援部,且有兩個營運工程師的配置,但還是常常會有Leaks或需要後送。

議題2. 是否一定要找到PO討論完才能決定是否動手解決?
插單優先序,PO認知是否該這個sprint處理 及 成員自主判斷優先序:
同調誤差率 5/27 = 18% (此項目包含: PO覺得該處理而未處理 及 PO覺得不該處理但處理 的數量有5個)

Good Smell: 大家價值觀跟判斷上的誤差率在可接受範圍。太棒了! PO的loading可以share出去了。而且大家價值觀差很接近,同時也代表產品熟悉度高,商業優先序及問題輕重緩急度大家對齊度很高。
Bad Smell: 資訊不透明。忘了考慮Ownership/不夠尊重Onwership。PO/SM沒辦法當防護網。Sprint Fail容易發生。
議題3: 插單的數量及完成率

插單完成率  17/27 = 62%

Good Smell: 這團隊真是棒,明明沒留太多Buffer,但可以完成這麼多插單的處理! 
Bad Smell: 呃~~ Sprint Goal 的 Commitment 擺哪裡了? 你看Sprint 又 Fail 了吧! Sprint 可以這樣 fail 又 fail 嗎?
議題4: 這些插單是不是自己以前種的因所長成的果

Bug占插單的比例 13/27 = 48%  (剩下的 14張包含有 out of story scope, undefined...這類就不算是Bug)

因上個Iteration沒做好而延伸出來需要處理的Bug,其插單率 7/27 = 26% (短期長尾)
更久之前的Interation沒做好,而延伸出來需要處理的Bug,其插單數量 6/27 = 22%(長期長尾)

Bad Smell: 插單的問題徵結,其實有一半數量是自己以前於程式碼中種下的因。(其餘的可能是 需求變更、先前產品未定義到、使用者的回饋.... etc 等產品需求grooming的議題)





 ( 上圖 - PO 與 Dev 一起討論判定插單 Task 的認知並標上記號 來協助統計及討論 )




綜合以上的資訊與討論,因此,有些議題的討論重點就可以轉移到另一個層次了:

議題1: 未跟PO討論就動手、找不到PO
因為 優先序的同調誤差率 只有 5/27 = 18%
轉變為 需尊重Ownership以及維持團隊資訊透明度。也就是,就算自己判斷完而先決定處理了,仍需盡速知會PO及相關權責/會被影響到的成員。

議題 2. 插單的處理流程確認為:
(1)第一時間研發同仁仍先確認問題所在
(2)ASAP 找PO 說明狀況 一起判讀情勢及影響
(3)設定優先序,以不同Post-IT顏色來區分。並且為了加速建立填寫共識,弄了個Sample示意,也實際貼出來。


( 新的標示法: 紅色 ASAP, 黃色 Sprint中處理, 綠色 以後找時間處理 )


議題3. 插單多,有一半原因是Bugs,因此,如何解決長尾:
(1) Ask for Help, ASAP. (不論是: scope不明確或是遇到障礙想問資深人員,或實作下去才發現有新的議題。甚至是如果找不到最合適人選求助或詢問時,也仍需思考是否有第二人選可問)
(2) 需加重來恢復力道的事: 提早找PO/BD人員使用玩玩 (潛藏心理: 自己做的不理想、沒信心就愈不想找人玩玩,需克服此種負向心理)
(3) 需加重來恢復力道的事: Rehersal 需找PO/BD人員。(頻次減少也與上述負向心理有關)
(4) 即早準備 Test Data 及 end-to-end testing scenario 與 Environment (可增強自己信心 讓大家可以走出「愈沒信心就愈想遮掩訊息、不肯即早面對使用者」的負向循環)


其中一名成員發下"豪"語:
我們的終極目標就是讓這塊板子消失



總結而言,這塊新的可視化插單看板發揮了很不錯的價值。雖然這個sprint之前,其實這些插單的統計是在Jira上,是團隊的Team Leader平常是有偷偷在記,但總沒辦法這麼透明的讓大家可以意識到問題的嚴重性及程度,大家反而比較不會有這樣的機會這麼正面且攤看來的去面對這些問題,不僅可以很快的去討論、歸類,並可以再去討論更深層的心理因素問題。

而這次的結果感受是,大家都很能公開透明的討論,並且追求好還要更好,心態上也更健康更有驅動力。



補充後記:
(2017/04/04補充) 提出插單看板可視化的成員 Howie 所撰寫的補充文章,請參見:
Scrum Team 中關於插單事件的視覺化的感想 

2017年3月16日 星期四

實體看板的再度邂逅


加入目前的團隊(TenMax & funP.com)接近二年了。這次想來講講團隊中的 Sprint 中發生的一個超乎我預期的變化,也很難得讓我開始又決定寫篇Blog來分享。

團隊大致上開始從redmine轉用Jira也有一年四個月了。但一直沒有什麼新的契機讓實體看板可以成真,而最近這些契機慢慢成熟,這次團隊的台北Campus中總算是有了一次行動,讓實體看板真的被做了出來,台北Campus的TenMax團隊一起好好的體驗了「有實體看板深度參與的一整個Sprint」。

而也在Sprint Retrospective,我們光是這個看板的價值及相關議題就進行了近 2個半小時的深度及延伸討論。

根據這次團隊的feedback回顧起來,加上我個人的見解,我覺得有幾個的關鍵practices, 促成了大家這次一面倒的全面肯定這個實體看板的價值:

  1. 大家每次 remote site concall daily scrum 後,都會聚在實體看板前來移動並分享一下,並互相分享與提醒。
  2. 客串的Scrum Master(註1),會問大家一些詢問式問題,而不是直接告訴該怎麼做才好,快速的進行了價值的溝通並形成認知共識。
  3. 拼貼、可移動、白板貼式的實體看板 創造遠比預期還好的化學反應。


而大家感受到的好處是(相較於先前 Jira 電子化且也一樣有規畫 Agile Board而言):


  • Task Review 的狀態大幅改善,每天確實都會互相提醒並預定早上的時間互相Review Task內容,因此 Ready to Review -> Done 的部份一直在增加。(pactices1+2+3產生的好效應)
  • 大家很清楚所有人目前的狀態是什麼,是否需要支援,會在有餘力狀況下主動承接或支援他人。彼此支援的行動增加了很多,不需統計數據列舉就很有感覺。(practice 1+2)
  • 對整體進度一目了然,不用翻頁、過濾,資訊狀態透明。(pactices1+2+3)
  • 團隊對於什麼是敏捷式看板的認知狀態是飛躍式的進展,而且認知一致。(pactices2)
  • 要調整優化看板的狀態是很容易的,而且當下就可以進行。(pactices3)
  • Sprint Retrospective中馬上就提出想要怎麼改善,以及打算Retospective完的隔天就要動手做勞作了。(因為拼貼式+白板貼 的優勢,遠比去想Jira上該怎麼調,考慮怎麼突破限制相比,這門檻真的太低太容易)(pactices3)
  • 如果討論過久,會議室booking時間到了需讓出,直接把白板帶到外面走廊就可以直接繼續討論並紀錄。(pactices3)


感受到的缺點少得多:

  • 大家很多時候狀態更新的心力改放在實體看板,而忘了Jira上也要更新(狀態、Assignee).





移動式、拼貼式的白板,先前在 facebook 上有分享過,就容我不再贅述,直接擺些圖來畫上句點。









(註1):為什麼說是客串的Scrum Master,其實是我們還沒走到真的可以有專職full time Scrum Master的階段。但團隊中有CSM認證的人有4~5人,可一直扮演團隊改善敏捷流程的潛在力量。

而詢問式的問題內容,舉例而言: 你看到了什麼? 有什麼覺得怪怪的地方? 這個Notation是什麼意思? 目前在Sprint要收尾的時間,這樣的分佈狀態是正常的嗎? 這個 Task 為什麼在Sprint要收尾的階段,還放在Todo? 是否做什麼樣的調整,這個看板更容易一目了然目前大家執行的狀態?

這種詢問式並且讓大家先想想然後發言的方式,個人覺得深化並建構認知的速度比前團隊還快上N倍,而且演化速度也比前團隊還快。大家在Retros的後2/3已經是完全在討論是否要追加什麼要改善些什麼了。

我想,很快的我又會有 看板演化 的故事可以跟大家分享。

#TenMax
#拼貼可移動式之白板貼實體看板





2015年3月27日 星期五

Scrum Master 的日常 - 以 Project GATE 為例


Scrum Master 這個在 Agile Scrum 框架之中的一個角色,常常是大家很關注的話題,但其實這個角色到底做些什麼事情、該由誰擔任,也是很多人很好奇或有滿腹疑惑的地方,常常會在社群分享的場合聽到下面的疑問:

  • Scrum Master這個角色到底做些什麼?
  • 該由什麼樣技能背景的人來擔任?
  • 怎麼決定誰來擔任這個角色的?
  • 這個角色可是 開發成員 或 部門主管 兼任一下嗎?

    (特別是許多剛接觸scrum概念的人,或有想要進行敏捷轉型的單位,特別會有這種問題)  

網路上可以蒐尋找到一堆scrum master的職責、定義,但Scrum Master的活動,到底像是什麼樣子,每天做些什麼,這些工作會花費這個角色多少時間,網路上的分享卻很少。

有些剛初接觸Agile Scrum的人,覺得這Scrum Master好像團隊內隨便抓個人來做就行,但在網路上爬了文之後,看到這個角色很多的定義與執掌,又覺得這角色包山包海,又能溝通又懂流程,簡直是要找個神人來才有辦法進行。

也因此,籍由本文先就我個人在Project GATE這個專案中,身為一個Scrum Master的角色下的工作項目以及其細節展開,藉此也讓有興趣的人透過生活照圖文了解一下,並從中反思,「為什麼 Scrum Master 由一個不負責工作開發的人來負責」、「Scrum Master需要具備什麼樣的特質及技能」





Part 1 - Sprint 進行中的日常工作 (Sprint Duty)

主持各類scrum活動會議

planning sum up 會議

  • 前置整理實際要開發的條目
  • 閱讀並檢查每一個被團隊挑選的user story
    • 是否有設定iteration / point(是否有輸入) / task時數(檢查時數是否合理)
    • task scope與 story描述是否合理
  • 預告本sprint預計會進行的會議並booking meeting時間
  • 主持會議


daily scrum

  • 統計消化時數 (實體看版)
  • 更新圖表 (實體看版 & 電子化資料)
    • burn-down, bug report, crash status
  • Milestone 時間軸移動

附圖1. Scrum Master在旁邊拿著手機,用著計算機app來算著大家的消化時數

附圖2. Scrum Master更新數據於實體看板上


polish time

  • 預告Polish活動
  • 主持polish time 並主持總結

    (註: polish time 是全team於sprint review前兩天,不分身份角色,一起自食狗食的時刻,讓大家可以透過實際使用去感受成品並發言提出見解)


review meeting

  • 會前確認各review版本狀態
  • 安排各小組的展示時間與順序
  • 主持並進行會議紀錄,視情況決定在自省會議是否討論
  • 引導進行檢閱電子化專案追蹤系統的狀態,確保sprint的結束狀態是同步及透明的。
  • 品質報告狀態
附圖3. Scrum Master 於 review meeting 主持議程


自省retrospective meeting

  • 提前整理前幾次會議的結論。
  • 主持會議並整理要點 (real time processing)。
  • 帶領 team member討論各種情境的成因、行動方案 或需另外舉辦會議討論。
  • 提醒refinement meeting booking。
       附圖4. 有幾次sprint failed,Scrum Master則介紹了 5-whys + 魚骨圖 的要因分析的方法,然後帶著團隊進行 sprint failed 的團隊自我檢討。


Part 2 - 不定期發生 (Executive Duty)

Project Duty:

  • 檢閱專案的中長期報表(cumulative flow, bug statistic, 各種leading/cycle time)並與團隊溝通解決其中的問題。
  • 蒐集並更新release roadmap
  • 主持release planning 
  • 敏捷式召募規畫及執行
  • 敏捷式協作空間的規畫與討論
  • 參與Product Owners會議
  • 參與Stakeholder會議
  • 新進成員的Agile Training 
附圖5-1. offsite meeting 的場勘,提前確認地點是否合宜並一起規劃活動。

附圖 5-2. offsite meeting的場外活動,scrum master跟著PO一起場勘,因為要在戶外實際使用自己開發的app,所以途中一直要以3G iPad不斷的確認訊號強度狀況,並規劃出合宜的活動(或藉機讓團隊體會什麼情境)。

附圖 5-3. 參與offsite meeting 的活動設計,也包含了許多引導團隊思考及討論、分類、規劃,以及創意提案競賽等活動(所有的活動其實都隱含著許多的敏捷、團隊精神及工法的引導)

Personal Duty:

  • 引導團隊形成共識及規範。
  • 確保並引導團隊成員按照團隊的規範與共識在進行。
  • 觀察團隊平常的協作及活動,並紀錄這些事件與現象。
  • 參與成員的績效考核或新人考核,並提供相關參考資訊。
  • 閱讀並消化敏捷相關議題的文獻、找尋合適的解決方案去解決團隊的問題。
  • 檢閱現有的開發流程、引導優化並確保成員遵守。
  • 360度協作與溝通
附圖6. 與單位主管們一起規劃出來的敏捷團隊協作空間。而Scrum Master 平時的位子位在看板區前,並且是一個方便做觀察者的樞鈕區(互動熱點區附近,可不動聲色的觀察中)




這兩部份所花的時間比例如下:

註: 時間參考的部份,是2014年四~五月間,透過Toggl這個 Time Tracking tool 記錄了一些Scrum Master的流水帳,所整理出來的。不過,這個比例其實並沒有把下班後投入的自修時間算在內。而且這個比例也隨著團隊的當時狀況,都可能有也都會有大比例的變動。



而Scrum Master最忙的時刻,其實是這些會議的前置準備期及主持這些會議。

而成員在開發的期間,Scrum Master做的事情其實就很多元跟鎖碎了,也因此,確保自身的敏捷化、適應性 對Scrum Master而言異常重要。大家可以想像一下,只要開發團隊中有出現了某些跡象,Scrum Master的天線就要對準這些發生點進行觀察,自己正在做的事情有時就需要停下來了,甚至必要時當下就要進行排解。

當然有些巷子內的看倌們可能會發現,我怎麼沒提到Scrum裡面一定會有的 planning meeting 與 refinement meeting ? 怎麼這個team中的scrum master從裡面人間蒸發了?

以結論而言,主要是因為近期的團隊與project scope增長,這兩個events 已經演進到是 multiple tracks同時進行,一方面是我沒有練分身術,一方面是成員也都已經都能掌握精神,所以我這個Scrum Master就變成只是列席,團隊有需要時再出席,只進行場外追蹤。




大家可以再回頭想想:

    Scrum Master這個角色該由什麼樣子技能背景的人來擔任? 

延伸思考:

    是 Scrum Master?   還是 Agile Coach?  


---
延伸閱讀:



2015年1月1日 星期四

精實軟體度量 讀後感

書名: 精實軟體度量
作者: 張松
審校: Teddy Chen
( 博客來網址參考 http://www.books.com.tw/products/0010624602 )


因緣際會之下,這本書終於在前一陣子入手。這兩周花了不少零碎的時間加緊把他閱讀完,將一些小心得跟佳言整理一下,也跟大家分享一下:

與 審校者 Teddy Chen 相似,我個人在內心上也是屬於 "對於「度量」沒有特別的好感" 的人。通常度量都是伴隨著 KPI 下的產物,團隊只注重一些數字  KPI 的狀況下,多數人其實會因此而變得價值觀扭曲,或變得不那麼在意一些具有 美德 的價值觀。而且我們也看過太多、聽過 一些過於注重 KPI 而將整個組職弄的腥風血雨,進而走上衰敗的案例。

但自己身為目前團隊的 Agile Coach,若沒有任何的度量方式做為依據,進而來支持著自己對團隊的觀點的論述,進而採取行動,也會覺得不夠 "有所本" 。也因此這本書其實之所以會吸引我,也是因為 Teddy 在序中所言 "這也許是一本那麼不會讓人討厭,而又與度量有關的書"。

而在讀完之後,對於這個書的評價跟感想則是:

對於平常就有大量的在閱讀敏捷社群文章以及實際經驗的人來說,應該會覺得這本書只是把這些知識以一個有系統的方式組織起來的一本經驗談。不過這其實也可以歸因為:精實(LEAN)的度量方法原本就是以輕量、有效為前題,所以並不會有太艱澀難懂的模型。

故這本書的價值會隨讀者對於這些內容的熟悉程度有很大不同的收獲程度,但對於敏捷方法的 組織架構、有哪些指標可以度量、如何建立有效的學習性組織 等議題涉獵還不深的人,或還沒有什麼想法的人,透過閱讀這本書,我想可以達到很不錯的起頭緒的作用。


自己看完後特別有感觸的佳言則是:

(1) page 146 「簡單的度量資料並不能將我們直接引向結論,更多時候是幫助我們提出有價值的問題,來發覺更多的資訊,以做出判斷,產生行動」
 page 264,265  團隊會排斥度量的其中一個關鍵因素是 "缺乏回饋"。「對於度量曝露的問題沒有行動,或是行動沒有結果,度量體系就形同虛設,大家也就沒有興趣關注了」

=> 直白一點而言就是: 沒採取有效行動去解決,度量的結果就也只是曝險而已,沒能產生更多價值

(2) page 157 在提到 任務中斷 或 context switch 問題的章節中: 「中斷會帶來許多負面的效果,但一味地拒絕中斷可能也會帶來問題,因此我們需要區別 中斷(Interrupt) 交流(Interaction)。交流可能導致團隊成員正在進行中的任務產生中斷,但兩相比較之下,交流所帶來的學習、創新、溝通的好處可能會大於中斷帶來的壞處」

=> 如何成功 「降低 Interrupt,增加 Interaction」,一直是敏捷團隊能否有辦法成功的關鍵。但產品所成員對於什麼是 Interrupt,什麼是Interaction的認知,恐怕就會有很大意見分岐了。也因此,"一個團隊"、"同理心" 很重要。

(3) page 203 「只有激發技術卓越追求的組織氛圍,才是持續促使員工技術提昇能力的根本」

=> 心中OS: 這一點好難阿~~~