插單看板可視化的誕生 ( 實體看板的再度邂逅系列 - 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 中關於插單事件的視覺化的感想 

實體看板的再度邂逅

加入目前的團隊(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
#拼貼可移動式之白板貼實體看板