【Scrum自省會議】Scrum新手懶人包，三種自省會議的開會方式！
在為Scrum回顧會議、自省會議而煩惱嗎？Scrum新手懶人包的「3個原則、4種結論、3種開會方式」幫助你快速上手Scrum自省會議！
為什麼要讀這篇文章?不論是Scrum的自省會議(Sprint Retrospective)，或是在專案結尾所開的檢討會、回顧會議，通常都有幾個問題:「問題太多檢討不完」、「鑽牛角尖無法解決」、「有了結論卻沒行動」。更可怕的情況，還會變成批鬥、責怪的大會，但如果能掌握Scrum中的一些精神，並以目標導向的方式開會，檢討會議其實可以簡單迅速就達成共識，並且在明天就展開行動。讀完之後你會知道?1.自省會議的目的、原則。
2.什麼是一個好的會議結論?
3.自省會議的3種流程。
碰過這樣的混亂？可能是檢討的方式錯了！
問題很多，檢討不完
我們的Scrum團隊在一開始嘗試自省會議時，就面臨這樣的問題:
一次Sprint包含著10~20個Story，每一個執行上都有些問題，但執行的人不但不同，以至於有時難以一起討論，甚至只檢討3個項目就超過會議時間。過了幾次後我們就發現，過往的問題不斷發生，卻遲遲沒有時間思考解決。
鑽牛角尖，或無法解決
為什麼才檢討3個就超過會議時間了呢？或許是因為我們時常鑽牛角尖，或持續對無法解決的事情討論。
例如，我們的產品結合著一道密碼鎖，但鎖體卻經常故障，讓我們產品無法正常運作。針對這個問題每個人都有想法，但細問下去又覺得不確定，都說「理論上可能是」這個原因，因此就難以繼續解決。
而當有人拿出證據時，又會被懷疑數據是不是正確的。就在沒有證據、懷疑數據的同時，會議就卡關了。
有了會議結論，卻沒有照著做
身為團隊的Scrum Master，對於所有會議卡關的現象，我都認為可以接受，但我們常面臨的最大問題，是每次開完會後事情沒被執行、問題一再發生，每發生一次，就宣判我們又開了一場沒什麼意義的會議了。
例如，我們曾經針對行銷宣傳的美術圖進行規範，包含顏色設定、大小、檔案格式等等，但後來的行銷宣傳，卻從來沒有照著執行過。
Scrum自省會議的目標是什麼?
如果你的團隊也常發生上面三個問題，那很可能是因為不清楚會議目標，或是沒有配套的行動原則。我暫時不針對這些問題一一解答，讓我們先從Scrum最初定義的「什麼是自省會議」開始聊起，相信大家會比較有方向。
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
The purpose of the Sprint Retrospective is to:‧Inspect how the last Sprint went with regards to people, relationships, process, and tools;‧Identify and order the major items that went well and potential improvements; and,‧Create a plan for implementing improvements to the way the Scrum Team does its work.By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint※補充許多團隊和我們當初一樣，會將檢視(Review)和自省(Retrospective)都看做回顧會議一併進行，但本質上這兩個會議是有差別的，前者確認執行的成果，後者在於優化執行的過程。．【Scrum檢視會議】開會報告沒意義?每個團隊都該學的Scrum回顧會議！
根據Scrum手冊，自省會議基本上就是
- 檢視整個Sprint的執行過程
- 針對有潛力的改善項目
- 提出可以在下一次Sprint執行的計畫
也就是說，檢視會議後會有個產品目標，而自省會議要想的，就是想如何讓團隊更快達成目標。
所以，在執行自省會議時，通常我會帶大家從檢視會議的結論看起。討論的範圍非常廣泛，包含人、工具、流程等等。
我們團隊通常不會限制討論的內容，只要是針對執行面的討論，都可以被納入。整個會議的時間，大概會按照2周工作量→開會1小時的比例進行。
而我認為自省會議最重要的，就是「提出可以在下一次Sprint執行的計畫」，如果沒有提出一些具體行動，通常會覺得自省會議沒什麼成效。為了達成這個目的，我想先針對「什麼是好的會議結論」、「開會應該有的原則」來討論。
什麼是好的會議結論，什麼是可以執行的計畫?
首先，我認為如果自省會議的結論，符合以下四種類型中任何一種，都會是一個將來可能可以被執行、不會被忽視的好計畫。
- 一個完整的User story，或一個清楚的Item
把一個確定的做法，直接變成User story或是Item放入Backlog裡面，常是一個很棒的結論。因為Backlog由PO掌管，每次Sprint都會拿出來看，如果討論可以有這樣的產出，可以說是十分幸運，畢竟能直接有解法的會議也是可遇不可求的。 - 建立一套新的標準、規則
結論如果是更改做事的原則，如「修改文件的規格」、「確立程式碼撰寫的原則」之類的，因為可以放入Scrum開發團隊的工作手冊之中，照理來說都可以很好地被傳遞、執行，也是個好的行動。（但前提是團隊要有此手冊，並習慣性地按標準作業） - 執行方法的修正
如果已經細到針對某個Item進行做法調整，可以直接在自省會就把要做的事情先列出來，不用等到下一個規劃會議再來規劃。 - 一件不確定什麼時候會做的事情
如果這件事之後會做，但沒辦法預期做的時間，也能算是好的結論，不過就該它放到執行時會參考的文件中。例如，這次替消費者辦了一場說明會，下一次辦可能是三個月後，那就把這次的檢討報告，放在下一次活動行事曆的備註中，讓執行人員可以想起來有這一份資料。
3個Scrum自省會議的討論建議
在介紹討論方式前，想先說說我對於自省討論的一些建議。
Scrum自省的大方向，其實就是針對正在做的事情進行調整，我們團隊有的時候會用聊天的方式，有的時候會投票，有時請大家各自沉澱思考，有時也會用Brain Storming創意的方式進行。
沒有什麼是絕對好或壞的方法，如果一個新手團隊不知道要如何開始，可以參考等等介紹的方式，如果都覺得太難，那就大家花1小時坐下來聊聊天也可以。
但依照經驗，我覺得大概有三個重點，可以幫助我們更釐清更完整的現況，並保持開會順暢。
「保持節奏」
開Scrum自省會議，我覺得最常遇到的就是莫名其妙卡住了，大家都覺得有個問題要解，但一時之間都不知道該說什麼。
例如，我們是一個外送平台，到底應該先找司機來外送，還是找到有需要外送東西的人。像這種很難的問題，會讓大家卡住、陷入沉默。而沉默超過1分鐘時，我通常會建議重新提問。
有時我甚至會先忽略這個議題，直接跳下一個，讓大家最後再回過頭來想，或再安排另一個會議思考。
有時，我們也會因為沒有足夠的證據支持而陷入爭論。像這種一時找不到證據的討論，我們就先進行數字或是邏輯的假設，讓討論可以繼續進行就好。
雖然沒有數字可以驗證，但我認為保持節奏感會讓討論氣氛更熱烈，會議結論也容易被接受，通常是比較舒服的一種狀況，與其陷入僵局，不如討論一個沒那麼重要，但可以讓會議繼續的議題。
「講感受，也講事實」
「我覺得…」常是會議常會出現的開頭，這沒有不好，畢竟看法、意見就是從這樣的開頭出發。不過當我們對同一件事情有衝突時，感受就不是一個好的討論基礎。最好再搭配一些具體數字，加上一句「事實上…」會更讓人更理解現況，也比要有說服力。
例如，A認為我們的產品功能不足、B認為產品功能太多了。這兩件事情都是感受，但彼此矛盾，以至於大家難以討論是否功能有問題。此時，不管刪減、增加功能都不太對。最好的做法，還是拿出消費者針對功能的評價，大家才有一個共同的討論基礎。
「多問幾個為什麼」
自省會議既然是要增加價值、改善流程，就不該流於太表面的討論，我們團隊很常犯的錯誤，就是「因為→所以」的推論太急，直到下一次的產出依然沒有有問題才會發現又自省失敗了。
例如「因為行銷曝光很低，所以購買量開始趨緩」這個問題，如果依據這樣的推論，我們可能就會想要打更多廣告。
但如果再多問幾次為什麼，如
「為什麼曝光很低?」→「因為我們沒有花很多行銷預算」；
「為什麼不花行銷預算」→「因為產品的特性，是要客戶口碑傳播才有效」
這樣問下去之後就發現，產品的特性會導致行銷方式有所不同，也會影響到行銷預算，最後結論反而不是多打廣告，可能是花更多心力來修改產品。
SCRUM新手懶人包，三種自省會議的開會方式
接著，就來介紹三種我們團隊嘗試過後的方法，再次提醒大家，討論方式各有優缺，每個團隊都可以用自己喜歡的方式進行，只要不脫離上面的目標及原則，應該都是不錯的Scrum自省會議。
MLGB便利貼蒐集法
- Step1. 蒐集資訊
這個方法其實就是Brain Storming，不過會一開始在白板上畫出「More、Less、Good、Bad」四個區塊來幫助大家發想。每人花5分鐘，拿起手邊的便利貼，把這次Sprint所想到的事情寫上，之後就貼到白板上。
可以是一句話、一個感覺、一個物品、一個工作流程。並且在整個過程中不溝通、不講話，如果可以的話，就用四種便利貼的顏色幫助區分。
- Step2. 了解資訊
此階段前半部，我們會花2分鐘左右，大家看看各自的便利貼內容，接下來3分鐘的時間，彼此提出看不懂的便利貼，並互相解答。 - Step3. 重新歸類
在了解所有的訊息後，用約3分鐘的時間，進行重新分類，把各自認為有關的便利貼擺在一起，讓他們看起來可變成一個故事。不用一開始就定義它們為什麼被擺一起，而中間也保持不講話、不溝通的方式。
- Step4. 投票
在歸類完之後，應該會有許多區塊，接著一人3票進行投票，選出想討論的3個話題。 - Step5. 進行討論
從最高票的項目開始，進行討論，一直到找出問題突破點，或是找出一個可以提高價值的方法，並把它寫下來。
這個方法的好處是，可在10分鐘左右的時間，搞清楚整個Sprint出現了那些特別事件，討論範圍可以拓得很廣，而且有容易讓大家理解，並快速濃縮成一個故事。對於新手團隊而言，能很快進入討論。
ORID焦點討論法
這是業界Scrum團隊比較常見的一種討論法，主要是幫助大家聚焦討論議題。而我們團隊有針對它進行了一些變形與改良。
- Step1. 說出事實 Objective
大家把自己想到的一個大的討論議題丟出來，一人最多2個，內容可以是「看到的、聽到的、發生的事情」。之後就進行投票，選出最重要的議題，並從它開始進行以下會議。 - Step2. 表達感受 Reflective
針對投票選出的題目，提出各種想法與反饋，可以是正面或反面。通常是比較心情面的東西。例如「開心、受到鼓舞、難過、沮喪」。 - Step3. 闡述意義 Interpretive
這個東西對團隊的意義是什麼、為什麼，則會會在這階段討論。通常我們會討論「會造成什麼影響?」「這影響大嗎?」「這是重要的嗎?」。 - Step4. 決定行動 Decisional
討論的結論，應該是盡可能把團隊覺得正面的事情持續下去，或是想辦法把煩惱消除，通常就是一個具體的行動。
我個人覺得這個方法不是很好，主因是硬要針對每件事情說出感受，其實很沒必要，而且常常一開始會不知道要寫什麼，所以我通常會融合上面MLGB方式，來幫助大家發想。
感受標籤法
經過幾次實驗，我發現各種方法都有優缺，於是我融合了MLGB和ORID的概念，發明了「感受標籤法」，實驗過後發現，如果要解決一些很細膩的問題，其實很不錯的！
這個方法中，大家一樣會提出事實，然後再接著利用以上標籤，替這些事實掛上一些意涵。讓大家更一目了然所有事件的感受。
而我通常會帶把同時有「應該要做」+「不喜歡」或是「應該要做」+「建議多做」的事情挑出來優先討論，因為它們通常是下一次可能會做的事情，或是最令大家苦惱的問題。
Scrum自省會議的結論檢查
除了優質的討論外，還建議每個團隊在Scrum自省會議的最後，都花個幾分鐘進行3個會議總結：
- 邏輯重述
把剛剛討論的重點快速描述一遍。 - 說出結論
說出每個議題最終的行動決議，最好包含負責人、執行時間。 - 放到檢查清單
建議PO或Scrum Mastet準備一張清單，用來放這些會議決定，並在日後持續追蹤執行的狀況，就像Backlog一樣。因為我們後來發現，如果沒有好好地記錄起來，很容一再過一兩次Sprint，我們又會開始討論類似的問題。或是討論完根本就沒有執行，以至於浪費討論的時間。
以上就是我們團隊自省會議的實作方式，以及我對於自省會議、檢討會議的一些看法，希望對大家有幫助。
※重點回顧:1.Scrum自省會議的目標
檢視整個Sprint執行的過程，然後針對有潛力的改善項目，提出可以在下一次Sprint執行的計畫。2.討論的建議
討論的3原則：「保持節奏」、「講感受，也講事實」、「多問幾個為什麼」
建議的4結論：「一個完整的User story/Iten」、「執行方法的修正」、「建立一套新的標準或規則」、「一件不確定什麼時候會做的事情」。3.可以用哪些方法來進行自省會議?
「MLGB便利貼蒐集法」、「ORID焦點討論法」、「感受標籤法」．※延伸閱讀:>>【SCRUM工作術】文章總表
>>【Scrum檢視會議】開會報告沒意義?每個團隊都該學的Scrum回顧會議！．「1下」拍手：到此一遊，留個記錄吧。
「5下」拍手：表示喜歡這篇文章。
「15下」拍手：表示你想要知道更多相關的內容！
「30下」拍手：手應該會有點痛，但還是歡迎繼續拍。按下「Follow」，追蹤我或我的專欄，將能定期收到優質的文章！
