為團隊量身制定回顧會議

回顧會議能協助團隊持續改善，即便是卓越的團隊亦是如此。一個撰寫財務軟體的團隊，他們在一個為期兩週的迭代結束時舉行回顧會議。這個團隊會輪流帶領回顧會議，本週正好輪到Dana帶領。讓我們檢視一下Dana在這場回顧會議中所做的事情。

Dana讓團隊了解回顧會議的目的、焦點及所需時間，並且告訴團隊將如何運用這段時間。她使用簡單的報到活動讓每個人都開口發言，並讓團隊再次檢視他們先前所建立的工作協議。

Dana檢視了團隊的缺陷資料，然後詢問這些事件與他們感到挫敗的地方。她這麼做是為了讓每個人都能思考相同的資料，而不僅僅是他們各自所認知的資料。她要求團隊檢查事實（缺陷資料）以及內心的感受（感到挫敗的地方）。

Dana帶領小組解讀這些資料，並辨別其中的模式。Dana協助小組辨識出各種不同的方法、再從中挑選出一個，並且規劃如何實現與回顧會議重點有關的目標。Dana果斷地結束會議。她向團隊確認他們將如何評估進度，並感謝他們的參與。

Dana依循了以下這個特定框架：1.開場（set the stage）。2.蒐集資料（gather data）。3.產生洞見（generate insights）。4.決定行動事項（decide what to do）。5.結束回顧會議（close the retrospective）。

此框架可在1小時內完成，也能擴展到3天。你可以透過增加新的活動來增添多樣性，但請堅守這個基本議程──此框架能滿足回顧會議所需的各個事項。

為團隊量身制定回顧會議

如果你帶領的是自己團隊的回顧會議，你大概早就了解整個團隊的歷史與背景。即便如此，請再檢視一次，以便確認你對團隊的歷史、士氣及專案狀態的假設都是正確的。

如果你是與自己團隊之外的團隊合作，請先研究他們的背景。你所蒐集的資訊將可協助你與團隊一起挑選出適合的目標。你所觀察到的事情將對於你需要問些什麼，以及團隊可能面臨什麼問題提供一些線索。

當你與團隊成員交談時，可對以下問題進行了解：

● 此迭代的產出是什麼？團隊的目標為何？他們如何達成（或未達成）預期結果？

● 先前專案審查的歷史資訊為何？發生了什麼事，以及後續處理的狀況為何？

● 當團隊進行回顧會議時，組織有發生哪些事情而影響了團隊？舉例來說，是否出現裁員的傳聞？最近有併購事件嗎？有產品被取消嗎？

● 團隊成員之間的關係為何──他們的工作如何相互依賴？他們的個人關係與工作關係為何？

● 團隊成員的感受為何？他們關心或焦慮哪些事？什麼事情能夠鼓舞他們？

● 對回顧會議的贊助者與團隊而言，實現什麼成果才值得投入這些時間？

● 團隊過去是如何與引導者合作的？

透過探索這些問題所萃取出的資訊，將可協助你制定可行的回顧會議目標。這些資訊也將協助你了解團體動態，並在你與大家還不熟識的時候，幫你建立關係。

制定回顧會議的目標

實用的目標有助於回答此問題：投入這些時間是為了實現什麼樣的成果？

一個實用的目標能解釋，為何團隊在尚未確定回顧會議之後會採取什麼行動或方向，就願意投入他們的時間參與會議。一個限制性的目標就像戴上眼罩一樣。選擇一個寬廣的目標，可讓你的團隊有機會發揮創意，思考過往的經驗，並找出他們認為重要的見解。與一般目標不同的是，你需要避免定義那些可具體衡量成果的目標，像是「決定如何說服人資部門取消績效評估」之類的目標，因為這會妨礙團隊考量其他的行動管道或是所面臨的其他重大議題。

這裡還有一個較為寬廣但仍然不恰當的目標：「確認測試任務出了什麼問題」。像這樣的目標可能會讓你的團隊走向錯誤的方向，也可能讓團隊開始相互指責。

實用的回顧會議目標包括：●找出可改善我們做法的方式。●找出我們做得好的地方。●了解沒有達成目標的背後原因。●找出可提升我們回應客戶能力的方法。●重建受損的關係。

以上只是一些範例。請考量你們的背景，並與團隊一起找出一個可以協助自身團隊的目標。

「持續流程改善」也許可在幾個迭代中發揮作用。在那之後，這個目標將變得不再適用。此時請切換到不同的目標。當你考量團隊背景之後，可向團隊推薦目標。如果團隊不認同此目標，就請團隊自行描述一個。

決定會議的時間長度

你們的回顧會議應該進行多久？這需要視情況而定。15分鐘可能足夠──但也可能不夠。回顧會議的時間長度並沒有既定的公式，而是需要取決於以下四個因素：●迭代的長度。●複雜性（技術面、與外部單位的關係，以及團隊組織）。●團隊規模。●衝突或長期爭論的程度。

為期一週的迭代可能花一小時開回顧會議就已足夠；為期三十天的迭代則可能需要半天的時間才夠。縮減會議時間意味著對結果作假（發布與專案結束時的回顧會議則需要更長的時間：至少一天，在某些情況下可能需要一至四天）。

複雜性可能與技術環境有關，也可能與關係層面有關。若你預計將有許多討論，請多預留一些時間。

人數較多時，也請增加時間。當會議超過15個人時，所有事項都需要耗費更長的時間。失敗的專案，以及受到政治干擾的專案會在團隊內部與外部引發長期的爭論。請多預留一些時間讓團隊成員宣洩吧。

如果成員找出有意義的改善方案，並在會議的預定結束時間前就完成了他們的規劃，你就可以隨時提前結束回顧會議。一旦團隊達成了會議目標，就沒有必要繼續該會議。不過，花太多的時間通常不是問題。反之，若你的團隊只產生了表面的見解與膚淺的計畫，那他們可能就需要更多的時間。

需要花多少時間準備回顧會議呢？

第一次嘗試進行一個並非只是詢問「哪些地方做得好？」與「我們應該在哪些地方改變？」的回顧會議，是需要花點時間準備。

需要多少時間？第一次所花的準備時間，可能會與所預計的回顧會議時間長度一樣。你會需要花時間去確認目標、決定會議的進行方式及流程、選擇活動，以及準備好如何帶領回顧會議。針對一個小時的回顧會議，你可能需要一個小時的準備時間。

之後的每一次，準備時間將越來越少。但你永遠不可能不花時間準備──若真是如此，那就表示你根本沒把這件事情放在心上。但透過練習，以及一系列讓你感到自在的活動，你就能夠很快地做好準備。

同樣地，第一次為發布或專案結束準備一個全天性的回顧會議，也會需要投入大量的時間。這很合理。如果你想讓5∼20個人花一整天一起學習，就需要確保你的會議能夠充分利用他們的時間，並獲得預期的成果。（摘錄整理自《Agile Retrospectives中文版》第一章，博碩文化提供）

 書名  Agile Retrospectives 中文版：這樣打造敏捷回顧會議，讓團隊從優秀邁向卓越

Esther Derby、Diana Larsen／著；敏捷回顧會議志工群／譯

博碩文化出版

定價：500元

 作者簡介 

Esther Derby

圖片來源／Esther Derby

以協助團隊達到高效生產力而為人所知。Esther的文章發表於《Better Software》、《Software Development》、《Cutter IT Journal》，以及《CrossTalk》等各大主流雜誌。她同時也是Amplifying Your Effectiveness（AYE）論壇的主持人。

Diana Larsen

圖片來源／Diana Larsen

擅長與軟體開發專案的領導者合作，以改善專案績效、支持並持續改變，以及打造協同合作的工作空間。Diana經常於軟體開發會議發表演講，並為《Software Development》、《At Work》、《Cutter IT Journal》雜誌以及《Cutter IT Journal》的〈Executive Update〉、〈e-Advisor〉系列撰寫文章。

Esther、Diana及Norm Kerth共同創辦了年度Retrospective Facilitators Gathering。Esther和Diana已經被公認是回顧會議引導方面的世界領導者。