# 停止回顧儀式，開始持續改善 - 柯仁傑 David Ko

> 從這開始共筆，您可以分享任何聽到、學到的事物

:::info
有些剛接觸敏捷的朋友, 看到公司在開 retro 會議 每次 Scrum Master 召開這個會議時, 會用到不同的引導方法. 看起來 Scrum Master 好厲害, 引導功力好棒, 可是每次會議都是在收集問題, 雖然有些 action item, 但是下次也沒有聽到那些 action item 的處理狀況. 就算有講一下上次 action item 的執行狀況, 但再下次可能就沒下文了, 很多東西真的能改一次就好了嗎? 沒有持續討論改進, 真的會有成果嗎? 是時候該使用別種方式來進行了!!

在這次分享中, 我們將會聊聊以下事情：
(1) 目前多數回顧會議的問題
(2) Improvement Kata 的定義和做法
(3) 如何利用教練技巧來輔助改善的進行

幫助你解決問題, 將改善能夠確實落地. 而不是收集問題, 或者是集體心理治療而已
:::

- 有執行回顧會議的不多，且執行的效果好像也沒有很好

# 回顧會議的問題
- 你進行過回顧會議嗎？
- 幾種進行的做法：SKS、海星(Start 、Doing、Stop Doing、Keep Doing、LESS of、More of)、帆船法、open space、ORID
- 上述方法的共同點是什麼？
- 收集問題
- 引導大家描述遭遇到的
- 買了一堆書就會比較懂Agile/DevOps嗎？[X]
- 議程架構的問題
- ＂上次＂提出的事情處理了如何呢？
- ＂上上次＂呢
- 問題並沒有處理，而只是每次都把問題再提出來
- 要改的東西很多，你要改哪一個？
- 沒有目標來引導
- 愛麗絲夢遊仙境的對話，＂這麼多條路應該走哪一條＂＂看你要去哪裡＂＂如果你不知道要去哪裡的話，走哪一條路都沒有差別＂
- 利用回顧會議改善，但怎麼知道問題和方案是對的
- 問題和方案是猜的，可是缺要求計畫落實執行
- 大多數人實施 Agile照著做但效果沒有很好
- 因為缺乏科學思維
- 從與其發生的情況與實際發生的情況，觀察差異從中學習

:::success
停止回顧儀式，開始持續改善
:::

`透過Improvement Kata與Coach Kata，把重點放在真正的改善`

# Improvement Kata
`小步前進、具體、數據`
- 什麼是Kata：結構性的練習步驟
- Improvement Kata 來自 Toyota
1. 明確方向和挑戰
2. 把握當前狀態
3. 確定下個目標狀態
- 不太可能一步登天
- 要有點挑戰
4. 為了達成目標的方案
- 一連串的PDCA

## Improvement Kata 特性
- 專注
- 先看下一個目標狀態
- 迭代
- 可能要好幾次才會到下個目標狀態
- 可操作的
- 方案有步驟且可衡量

## 案例：加班很嚴重
- 理想：工作能在上班時間內做完
- 現況：會開不完事情也做不多
- 目標：紀錄工時，第一個Milestone是分析每美類活動的時間、比例
- 目標：分析瓶頸
- 目標：專注開發時間

# 如何落實 Improvement Kata

## Improvement Theme Kata
- 畫出圖，用便利貼的方式視覺化的討論

### Improvement Theme Kata 範例
- Theme：增加足夠的品質確認活動
- 現狀
- 故事開發後只是簡單的手動測試
- 沒有回歸測試
- 單元測試都是之前舊的
- 驚奇的境界：
- 每個故事開發後都會有單元測試
- 有自動化BVT
- 會進行探索性測試
- 兩周後
- 探索性測試訓練
- 單元測試開始增加
- 下一步工作
- 安排訓練課程
- 通知PO此項決定
- 在迭代規劃時安排單元
- 測試的任務

## 利用簡單的動作，建立肌肉記憶才能持之以恆
- 把步驟縮小，能重複練習

## 沒痛沒動機
- 把最痛找出來，否則做改善沒有實質幫助的情況下，最後會不了了之

## 小步前進
- 通常大家會太樂觀看要做的下一步，但每次迭代通常都沒有把全部的事情做完，表示光寫功能就做不完了，哪還有時間改善
- 訂出最小可行改變

## 具體的行動步驟
- 沒有具體步驟，每個人做的都會不同
- 例如：開會要有效率較好的步驟是把會前會中會後的具體步驟列出來。

## 要有衡量的指標
- 沒有衡量就不知道有沒有做好
- 為改進項目定義做好的標準
- 例如為每個story撰寫驗收標準(AC)

## 即時回饋
- 每天隨時隨地給團隊成員回饋做得好不好，不是時間到才回饋

## 縮短練習頻率＋刻意練習
- 不熟就不做，不做就不熟
- 週期縮短馬上能看到成效

## 慶祝成功
- 贏是一種催化劑
- 要刻意慶祝那些地方做得好，讓大家有想保持成功的使命感

## 比馬龍效應-相信員工
- 認為員工自己可以做好，一旦有進度就讚美鼓勵他

# 經理也是關鍵：Coach Kata
`耐心、關心、專心`
- 跑 Agile，DevOps一定要去管理層嗎？
- 在LEAN的想法管理層也是有幫助的
- 讓經理扮演導師的角色，分享他的經驗，讓大家少走冤枉路
- 第一線觀察員工，可以給員工回饋

## Coach Kata
- 培養教練技能
- 幫助管理人員教授改進型思維和行動
- 每天進行20分鐘
- 為了達成目標而努力
- 幫助大家更專注

## 教練過程－釐清事實（O）
- 你的下一步目標狀態是什麼？
- 那目前的狀態是什麼？
- 你最後一步做了什麼改善？
## 教練過程－了解感受和意義(RI)
- 你預期會有什麼結果？
- 那真實的結果是什麼？
- 從中你學到了什麼？
-> 讓他自己反思了解其中的差異

## 教練過程－決定行動(D)
- 若是要達到下一步目標時，你遇到什麼阻礙？
- 下一步你打算先處理什麼阻礙？預期有什麼結果？
- 什麼時候可以看看這個步驟的成果，以及你學到了什麼？

## 新手教練
- 好奇和關心被教練的團隊讓團隊回答出有用的答案：
- 剛開始時太愛自己，在意流程、在意進展->要好奇和關心團隊
- 讓數據說話
- 記錄執行過程
- 要讓事實講話，才不會過度專注在人，Coach才會成功
- 其他
- 不要給團隊壓力
- 慢慢問慢慢反應
- 不要打斷團隊說話
- 失敗並不可怕
- 每次只針對一件事

# Q&A

- 要怎麼找到待改善的目標(也就是北極星)？有很多改善的目標時要選哪一個？是由團隊一起集體討論對嗎？感覺蠻容易變成由主管或PO決定？
- 團隊一起討論，要找出最痛，否則團隊興趣缺缺
- 跑三四次之後自己也要覆盤方向對不對
- 北極星通常只是個目標，每兩三次之後就可以重新校對一次

- AC是從PO開始寫嗎？如果PO不是很會寫AC，團隊可以怎麼給予協助？SM可以怎麼給予協助？如果PO是從waterfall轉過來的，對於寫AC還是很容易變成以前的寫需求習慣，那可以怎麼給PO協助？謝謝老師
- PO可以起頭寫一些，但如果都要PO寫會變成瓶頸，請工程師幫忙寫，PO再來Review
- 把AC想向成test case，會有明確的input process 及 output