激發見解（Generate insight）

到了這激發見解的階段，就可以透過上階段得到的回饋資訊去收斂，思考要怎麼改善上階段提出的缺陷、或是維持做得好的部分。這階段就可以嘗試透過比較明確的問題或活動去引導團隊開始去思考解決方案，通常會從三個方向去發想：

1. 目前做得不錯，應該要制定政策去持續的。
2. 目前做得不好，應該明定政策去避免的。
3. 有什麼是你覺得可以嘗試去做的，以改善現在存在的困境。

前兩個問題的表現不一定是整個團隊都有的，可能是其中某幾個成員，但卻也可以嘗試制定政策。比如說我看到某甲在開發時都有用 Linter 去讓程式碼風格保持一致，覺得這樣很棒，這樣可以讓我們不用在 Code Review 時還要人工去盯程式碼風格，或許這件事可以推廣到整個團隊，於是我就在這個階段提出；或是我覺得常常在寫程式時一直被同事以不重要的事情打斷，我就可以提議不需要緊急處理的事情不應該直接去打擾正在寫程式的工程師。第三個問題就比較偏向做出點創新或改變，比如說我在上個階段發現到大家對於程式碼主線常有一些壞掉的程式碼感到很困擾，我就在這個階段提議或許我們可以導入 Code Review，或是另外再提議用 CI 幫忙把關。

所以這個階段的活動主要就是要能去引導團隊藉由上階段所得到的資訊去思考這三個問題，像是 Brainstorming (#10) 就是給成員一段時間去思考可以有什麼建議將他寫下來、如果上個階段是透過 The Speed Boat Game (#19) 發想，也可以直接讓大家透過不同顏色的便利貼將想法貼在對應的問題上、5 Whys (#8) 則引導大家去思考問題產生的原因，透過不斷詢問找到肇因，從根本去思考解決方向。

做出決策（Decide what to do）

我們在上個階段會得到許多想法，所以通常在上這個階段收尾、或是這個階段時，透過投票或是類似形式，決議出最認同的建議，或是最重要的議題。比較簡單的方式就是透過貼紙投票的方式去排序、也可以先選出前四到六個最認同的建議後，建立一個討論空間讓團隊再次抉擇，像是 Pitch (#73)。如果這之中的建議都足夠明確，就可以直接作為下一次衝刺進行的政策。

除了選出最重要、最認同在下次衝刺應該執行的建議外，這個階段另一個重要的事情就是要將這個想法制定成可執行的政策。這時候我們就可以選擇使用 SMART Goals (#13) 的方式，針對 Specific（明確）、Measurable（可衡量）、Achievable（可達成）、Relevant（相關）、Time-bound（時限）五個方向去思考如何讓想法變成一個可以努力的目標。若是前面得到的建議不夠完整時，就很需要透過類似這種方式去讓政策更加明確，避免最後功虧一簣、不了了之。

在引導團隊去完善政策時，也要避免讓他們想要一次定義出一個完美的政策導致鑽牛角尖、或是走入死胡同最後想不出來。而是要讓他們認知到是以建立一個實驗性的政策為目標，這個政策要達成的目標可以小，但至少要團隊有辦法達成的、這個政策不一定訂了之後就不能更動，是可以針對之後的觀察再去做調整的這樣的心態去訂定政策。

結束會議（Close the retrospective）

當制定完政策後，這個會議也就達成目的了。但是在會議結束前，我們仍要透過個小活動進行收尾。在這個階段的活動設計，會比較偏向讓團隊去檢視整個回顧會議得到的資訊、或是回顧這個會議的流程，讓團隊和主持人知道大家對於這個會議的感受、或是有沒有什麼可以改善的建議。例如 Meeting Satisfaction Histogram (#87) 就是透過簡單的刻度表去搜集大家對這個回顧會議的滿意度。

也有一個設計方向是讓團隊彼此激勵，以建立彼此積極的動力，以及持續改善的衝勁，像是 My Team is Awesome (#120) 就是此類。