跨團隊深度 Retro 心法：一起跑一場有建設性的回顧會議！
如果你的公司採用 Scrum 的方式進行產品開發，相信你對於 Retrospective （回顧會議）應該不陌生：在 Scrum 的流程中，團隊會在每個 Sprint 結束後，針對 Sprint 內容與執行狀況來 Retro，藉由回顧每次的執行過程和經驗，調整工作流程或合作方式，進而提升未來 Sprint 的效率。
網路上也有很多 Retrospective 的參考架構，像是設計思考流程愛用的 I like / I wish / What if ，這個方法能夠有效把批評轉成改善的願望，討論起來的氣氛會比較輕鬆愉快。我以前也常用 Best / Good / Better / Bad 的框架來分類，慶祝團隊成功的同時，也協助團隊專注在「Better」也就是真的可以改進的部分，認清那些一次性的意外或外在因素「Bad」，並且保留緩衝時間來應對。
個人認為以上這些架構在跑 Scrum 的情境都還蠻好用，畢竟只有一至兩週的執行內容，對事件記憶猶新，使用以上框架即能夠蠻好的分類與討論。
不過久了之後大家可能也會發現，很多問題並不是單一原因所造成的。
羅馬不是一天造成的，意外會發生通常也不是一個人的問題。有名的「乳酪理論（Swiss Cheese Model）」就是在描述類似的狀況：每一層起司都有許多漏洞，當這些洞連成了一線，變成可以從頭穿破到底的大洞，就像是每一場意外湊巧同時穿過每一道防護措施的漏洞一樣，不預期的問題或意外就會在這些漏洞串連的時候被發生。
我曾遇過一個意外事件：功能上線近一年後，我們才發現其他功能的邏輯被影響、並可能影響重要指標。在這一年間，有經歷組織變動、策略轉彎、其他團隊跑的相關 AB test…..
面對像這樣非單一原因或長期積累而造成的事件，其實並不是那麼容易追朔原因，在過程中也有許多不同部門的人參與，所以當時的我們急需更深入的對話方式，可以好好釐清前因後果。
我在事件當下剛好被指定為 Retro 的負責人，參考了一些人的想法之後試著用一種不同於以上框架的方式跑跑看更專注版的 Retro，沒想到會開完之後參與者的回饋都蠻正向的，以下就跟大家娓娓道來：
用「故事接龍法」跑一場有建設性的 Retro
為什麼我把它叫做故事接龍法呢？顧名思義，這會是一場以時間線說故事，釐清來龍去脈的回顧方式。（不好意思這名詞是我自己亂想的，如果有更好的名字歡迎投稿跟我說哈哈哈）
第一步：故事接龍
建議大家在開會前就先準備一份時間軸，盡量把所有已知資訊（例如決策時間、內容、相關資料和人名）寫上。而會議發起人一定要跟大家說明，這份文件絕對不是為了要指名道姓說誰在哪一步做錯，而是為了讓所有參與者都可以知道前因後果。
開會的時候，主持人要帶著所有人一步一步的「說故事」，請每個決策點的負責人說明當時的情況，在什麼情境下做了什麼事情、是什麼原因或動機，如果現場有人有疑問就馬上釐清，並且補充細節到文件中當作會議記錄，就這樣「故事接龍」般的把整件事情說明完畢。（我用這個架構跑了三次以上的跨團隊 Retro，很有趣的是，就算事前文件準備得再怎麼詳盡，在開會的時候一定會有人說出你不知道的事情和原因。）
第二步：分析原因
確認大家都說完故事後，先別急著跳到解決方案！接下來是「分析時間」，討論看看到底有哪些根本原因造成此次意外，原因可能是流程的缺陷、可能是新人對產品或公司的不熟悉等等，這些原因可能很多、很深、甚至還互相相關，可以盡量都寫下來再統整沒關係。
建議在這一步的時候盡量讓每個參與者都能發言，看事情的角度不同，可能會有不同的想法，同時也尊重每個人的觀點。
第三步：發想解法
接著就是對剛剛分析出來的根本原因找解法了！解決方案的發想我相信對大家都不是問題，記得寫下 Action Points，替每項改進項目指定負責人。在這邊 Retro 就大功告成了啊！
在時間分配上，我會建議花六到八成的時間「說故事」，充分了解事情始末，剩下的時間再來分析與討論解決方案。當大家必須專注在描述事實、了解問題，就不容易被解決方案給分心，而當事情的脈絡清晰時，之後的討論會更容易對症下藥；另一方面，大家在說故事的途中也會漸漸明白別人為什麼當時做了這些事情，能夠更加同理別人，進而達成「Retro as a team」的效果。
故事接龍法使用時的五大原則
原則一：設定清晰的目標和 Outcome
在寄送會議邀請之前，多問問自己為什麼想要跑這場 Retro？是要提升團隊精神與士氣？還是要趕快補救意外事件？抑或是希望改善團隊工作流程呢？結束會議之後，你又期待有什麼樣的不同呢？
一個清晰的目標可以幫助大家專注在同一件事情上，當參與者收到會議邀請的時候，也更容易理解你舉辦 Retro 的目的。
原則二：邀請所有與決策相關的同事
通常像這樣的意外中，相關的每個人可能都各自擁有片段的資訊，甚至不同部門或團隊的人也可能會有不同角度的看法。唯有資訊完整，才有辦法了解事情的全貌，進而用正確的方法去修復問題。
寄送會議邀請時，可以邀請過程中有參與決策的人、受本次意外影響的人、還有可能有辦法協助解決問題的人等等。我之前是邀請各團隊的代表，人數在十人以下，還沒試過用這個框架套到更大型的會議。
原則三：協助參與者建立正確的心態
這一點非常非常關鍵啊！主持人在寄送邀請與Retro 開場的時候，一定要告訴參與者：「這一場會議，我們不是要抓戰犯、指責對方，我們只是要了解事情怎麼發生的，一起想辦法解決問題、協助整個團隊變得更好。請不要人身攻擊、不要隨意下定論，我們先一起了解事情的始末，再來看看怎麼做最好。」
主持人的心態也很關鍵，盡量把自己當成中立第三人，以搜集資料的想法去問問題。在過程中若發現參與者偏離故事線開始講不相關的事情，可以把話題拉回來，重複上述的觀點，協助團隊理性討論。
我自己是相信任何事情都有它的原因，也相信很多問題都是來自組織或流程的錯誤，也因此我在主持會議時真的打從心底的不覺得任何人有錯，這心態能夠幫助會議氣氛歡樂不少。
原則四：對事實坦白、說明決策原因和動機
「我當時決定⋯，因為⋯。接下來我把這件事情⋯，因為⋯。」
說故事的重點就是要說出事實，務必要說出當時的 Context 和原因。試試看把每一句話都接上「因為」 吧！
當每個人都說出他這樣做的原因和動機的時候，我們就會慢慢的知道事情為什麼這樣演變、這樣發生。過程中如果有覺得不合理的地方，請不要批評別人「這樣不對」「這樣不合理」，先友善的詢問「為什麼」才是上策。
原則五：不要在接龍途中討論根本原因和解決方案
在討論過程中很容易跳入細節，但別急別急！我們等下還有充分的時間分析與討論解法，先專注在事情本身可以有效的協助團隊看見事情全貌。
故事接龍法的優缺點
- 適合對於同一個事件深度討論，不適合討論多分支的故事線
- 特別適合跨團隊或長期積累的的複雜問題，如果只是顯而易見的小失誤並不需要用到此方法
- 一個可能要邀請五到十人、花一兩小時的會議很花資源，建議大家只對關鍵意外使用
整體來說，平常時間還是用大家習慣的 Retro 架構跑 Scrum，若有比較複雜的議題，可以搭配這個故事接龍法來服用。
故事接龍法服用心得
雖然每次要跑這種跨團隊的 Retro 其實都沒什麼好事發生，但是我發現其實大家會有誤會有批評，都是因為不夠了解事情「為什麼」會變成這樣。
我不知道是不是也有其他人在用類似的方法跑 Retro，但我自己覺得這個方式讓團隊可以很專注在事情本身，也創造了很棒的團隊精神，每次開完會都意外的神清氣爽。如果下次不巧碰到類似的狀況，也不妨試試看！歡迎大家跟我分享你們的使用心得唷。
2021/04 更新 — 讀者補充：哈佛商業評論上曾經描述過類似的作法，叫做 After action review：https://en.wikipedia.org/wiki/After-action_review 如果有興趣的話也可以用這個關鍵字多找資料！
謝謝你的閱讀！如果有任何疑問也歡迎留言給我 📒
如果單純想給我一點鼓勵，請給我 1–10 個拍手；
如果覺得文章對你有點幫助，請給我 11-20 個拍手；
如果想看更多此類型文章，請盡情長按拍手（50個拍好拍滿也沒問題）讓我知道 👏🏻想要持續追蹤我們的最新文章，請追蹤產品三眼怪實驗室 (◉◉◉)
