優秀的團隊用「成果」評斷回顧的價值。如果可以像星艦企業號的 Picard 艦長一樣說「Make it so」就夠了該有多好——可惜真實世界不是這樣。行動計畫只是改變的起點，將實驗納入下個 Iteration 的工作計畫能確保它被注意——但有時候還是不夠。

改變舊習慣，幾乎不可能單靠「停下來」達成；用一個新行為去取代舊行為更容易。團隊與組織也是如此。

案例：沒有替代行為的回退#

Lynn 的團隊在回顧中決定「不再沒計畫就跳進寫程式」。但下次 Iteration 規劃時，兩位成員打開筆電想分享他們週末寫好的 code——他們以為是在搶先一步。

Lynn 提醒大家原本的協議，並分享他在敏捷討論群讀到的幾個規劃方法。團隊決定堅守協議並試試 Lynn 的點子。當他們真的逐項討論工作後才發現：週末寫的那段 code 對 Iteration 的目標毫無幫助——是純粹的浪費。

沒有替代方案，團隊就只能回到舊行為。新行為一開始都笨拙，學新發球或新語言一樣，要靠練習成熟。給予支持、容許犯錯。

提供支援#

回顧結束不代表改變的工作結束。即使是小改變也需要被滋養與支持。

五種支援形式#

強化（Reinforcement）#

給予具體的回饋：描述行為、說明影響。例如「我注意到昨天的站立會議我們守住了四個問題，這真的讓我看清楚障礙在哪。」

同理#

別像 Fred 那樣對 Katie 說「我想過了，你沒理由有那種感覺。」這不是同理。

同理是承認對方的觀點與感受（不必同意要修補狀況）。一句「我聽到了」往往就足夠。

學習機會#

• 無預算可做：brown-bag 午餐、分享會、提供文章與資源、找內外部 mentor、鼓勵配對程式設計學新語言
• 有預算時：投資訓練建立基礎，建立資源圖書庫

練習機會#

練習才能熟練。可以「在真實產品上試新方法」，也可以建立正式的練習空間。

• Short-Short Project：1 至 2 天甚至更短的小專案，用來探索方案或試新方法。對不會 timebox 的團隊一舉兩得：時間限制本身就是學習點
• Practice Area：不會影響真實產品的測試／開發區
• Hello World：最小程式，能快速驗證環境配置或概念可行性

提醒#

• 大型可視圖表：Terry 的團隊每完成一次重構就貼綠點到大圖上，每天結束時 review，讓重構保持顯眼
• Check-in：「用一兩個字描述我們估算做得如何？」短問題快速量測新做法的進展

共擔責任#

當改變的責任長期落在同一個人身上，會出現三個問題：

• 英雄化：團隊把某成員視為「拯救者」，破壞共同擁有感
• 學會無助：當（非系統性問題的）責任永遠落到正式或非正式的領導者身上，等於教團隊當受害者
• 代罪羔羊：當問題解決責任固定指派給內部某個小組，會形成「他們是所有問題的源頭」的觀感

共擔責任，並輪流由不同人領導改變。

支援更大的改變#

Iteration 回顧通常產出小範圍的改變；發版／專案回顧則可能產出耗時較長、影響更廣的改變，需要更多支援。

改變的四個階段#

即使是自己選擇與計畫的改變，人仍會經歷可預期的過渡階段。理解這四階段能幫助你支援團隊。

1. Loss（失落）
   • 開始新事物前必先放下舊的
   • 失去的可能是能力感、領地、關係、確定性
   • 對新東西的興奮可能讓人快速通過此階段，否則需要更長時間調整
   • 不放手，就無法前進
2. Chaos（混亂）
   • 放下舊的不代表理解新的
   • 人們會困惑並嘗試重新定位自己
   • 規則尚未定型反而能激發創新——可能在此誕生新做法
3. Transforming Idea（轉化想法）
   • 經由實驗與探索，人們開始看見新方式如何運作
   • 外來觀點可能成為觸發
   • 開始試新行為與新點子
4. Practice and Integration（練習與整合）
   • 想法本身不夠，需要練習才能熟練
   • 績效可能初期下滑，但會隨練習提升

支持改變的三個面向#

1. 識別人們珍視的東西#

找出舊方式中被珍視的價值，看怎麼把這份價值帶到新方式裡。承認舊方式有其價值，等於承認大家不是當年「笨」或「錯」——這讓人更願意改變。

範例：Lakshmi 的團隊因產品成功要擴員 50%。一方面興奮，另一方面失落原本的小團隊凝聚感。團隊負責人在新人加入前，先釐清團隊的價值與想保留的實踐，幫成員把「最重要的東西」帶進更大的團隊。

2. 建立暫時結構#

暫時結構幫助人們穿越「混亂」階段——可能是計畫、角色、會議、方法，任何能銜接「現狀」與「目標狀態」的機制。

範例：Franz 的團隊做高科技醫療裝置，受嚴格法規管制。要轉向 XP，但業務端不放心拋棄需求文件、改用故事卡。團隊的暫時結構是：

• 接受業務的需求文件
• 在每個 Iteration 把需求轉為故事
• 每個 Iteration 結束展示軟體並說明「故事 ↔ 需求」的對應
• 幾個 Iteration 後，業務端開始看見「故事」的價值，並設計出可供法規追溯的方式

3. 控制資訊與謠言#

改變發生時人們渴求資訊。資訊不足，他們會用最壞的恐懼填補空白——即使是小團隊也會有謠言。

範例：某團隊建立 Rumor Control Bulletin Board，任何人聽到謠言就寫卡貼上，大家可以一起追查事實再貼上更新。除了壓制謠言，這個機制本身也傳遞訊號：「你聽到的很多並非事實」——讓成員學會核實再傳。

結語#

回顧能成為改變的強力催化劑。一場回顧可能就是大規模轉型的起點。但漸進式改善同樣重要——值得慶祝，因為很多團隊從未做到。