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