如何讓人在自省例會 (retrospective meeting) 說真話？

最近看到一串關於 retrospective meeting 的討論：

大意就是苦主感嘆 retrospective meeting 是最難開的會，真實的意見往往人走了才會說。都抱著要走的決心了，還有什麼不能或不敢說的?

但據我觀察及個人親身經歷：那些決定要走的人，往往最難得到真實意見。不是不能說、不敢說，而是不想說。

當人選擇主動離開，無論原因為何，最終的結果就是離開公司。大家都希望好聚好散，能在 retrospective meeting 上說的話自然就變成以不得罪人為前提進行。想想看，一個明天就要走的家伙在這對公司指指點點，這個配備太爛、那個流程太煩瑣…不覺得很想從他頭上貓下去嗎?

今天就來討論一下，如何讓人在 retrospective meeting 說真話吧：

1. 不分組

兩個團隊，在 retrospective meeting 中對於順序採用了不同的作法：團隊 A 讓大家隨便坐，每個人輪流發表；團隊 B 則以小組為單位發表。

我認為團隊 A 比較容易得到真實的聲音，小組為單位的發表通常由小組長先進行說明，若沒有提出什麼問題，組員比較容易為了"和蟹"而將原本想說的話吞回去。

另外，以小組為單位容易讓焦點專注在與小組相關的事務上而忽略與流程、團隊相關的事情。如常聽到的是：這週 iOS 組都很順利，沒什麼問題。但你觀察到的問題並非與 iOS 組極度相關，可能是發現老闆和其他組的問題，因為焦點 focus 在 iOS 上而忘了或不想說。

2. 每個人一定要提出好的事項及待改善的事項

這似乎是 retrospective meeting 的基本要素之一。不過若是寫在教料書上，而沒有真正落實，往往只變成一個報喜不報優的會議。

我遇到的經驗是：PM 直接詢問，本週有沒有發生什麼事啊？雖然聽起來可以說好的，也可以說不好的，不過少了強制力，人就比較偏向不講壞話，再加上搭配 1) 小組詢問就好像有點變成：有什麼問題不就是我小組長的錯了嗎？這樣我還會跟你說發生了什麼問題嗎？

怎麼真正落實？我們的做法是發一張紙、給個 5-10 分鐘，請每人在紙下寫下好的事及待改善的事，發表時也必須按條宣告 1) 好的事 2) 待改進事項。如此強迫每個人去思考在這個 sprint 中發生的事情，也比較容易讓人講出(寫出)真實的話。

3. 對於提出的待改善事項也一併提出解決辦法

retrospective meeting 上的意見往往都是比較敏感的問題，一個不小心聽起來很像是抱怨。但若是提出待改善事項的同時也要想出一個解決辦法並提出來，對於提出的人會有比較好的心理建設：我不是只有打嘴炮抱怨，這可是有解決辦法的! 聽的人也比較容易接受。

如：這個 sprint 我改一個功能發現要改 20 幾個地方，這 code 有問題!

變成

這個 sprint 我改一個功能發現要改 20 幾個地方，建議 CI 導入 DRY plugin ，追蹤並試著降低 duplicate code 。

是不是馬上就從抱怨變的有建設性的一個可改進項目。

4. 最重要的一步也是最困難的一步，正視並真的去解決提出的問題

團隊內部問題相對好解決，我們的做法會把大家想先解決的問題寫下來並貼在白版上，如：透過 API 文件讓 server-client 整合更加順利，在下個 sprint 的 retrospective meeting 檢討是否有落實並解決我們想解決的問題? 沒有的話問題出在哪?

如此的做法，可以讓團隊成員明顯的感受到提出的意見真的有被聽進去，而且是被視覺化的追蹤，不會莫名的消失在某個黑暗角落! 我們冒著黑掉的風險提出的意見真的有被接受而且對團隊產生了正面的影響! 這種顯而易見的回饋會是下次團隊成員再次提出真實建議最好的鼓勵。

團隊外部就相當困難了，除了強大的 scrum master 支援、夠力的 manager 外，我也還沒到那個層級去處理那些問題。

2014.1.21