敏捷方法能夠奏效, 有一個很關鍵的地方, 就是利用 Retrospective 會議, 檢視目前做事方法, 看看哪邊可改善. 也就是透過 PDCA (Plan, Do, Check, Act) 的循環, 小步前進, 快速檢視, 快速調整. 因此, 在 LeSS 中, Retrospective 也是一個重要的環節.

在 LeSS 中, Retrospective 分成兩個部分：(如下圖所示)
(1) Team Retrospective
是由團隊自己所進行, 和 Scrum 中的 Sprint Retrospective 一樣.

(2) Overall Retrospective
各個團隊派代表來參加. 這是 LeSS 增加的, 在下篇文章中會介紹.

圖片來源: https://less.works/less/framework/retrospective

讓我們來看看 Team Retrospective 會議的一些注意事項：

這個會議通常是在迭代最後一天舉行. 在 Sprint Review 會議之後, 這個會議舉行完後, 才進行 Overall Retrospective 會議.

Sprint Retrospective 的重點是團隊成員. Scrum Master 可以扮演引導的角色. 很多時候 LeSS 團隊只有一個 Scrum Master, 因此他可能無法參加所有團隊的 Retrospective 會議, 團隊成員會需要自己找人來引導會議的進行. 或者是讓 Team Retrospective 會議錯開, 讓 Scrum Master 都可以參加去幫助團隊. 不過這樣時間會拖比較長. 當團隊數目一多時, 這樣的做法就不太實際. 因此, 適當訓練團隊成員來引導, 或者是找外部的 Scrum Master或中立的成員來主持, 都是可能的作法.

Sprint Retrospective 是有 timebox 的, 不會沒有限制無限延長的. 要決定多長, 可以參考一下元素：

• 團隊中有多少參與者？
• 是否有任何團隊成員是遠程參與
• 團隊成員有多新

如果上述狀況人數越多, 通常會需要的時間也會比較多.

至於 Retrospective 進行的方式, 目前已經是很成熟了, 有不少書籍在介紹. 下面便是一些熱門和常見的好書, 有興趣的朋友可以自行去購買.

(1) Agile Retrospectives: Making Good Teams Great, Esther Derby
(2) Retrospectives Antipatterns, Aino Vonge Corry 和 Pearson
(3) Improving Agile Retrospectives: Helping Teams Become More Efficient (Addison-Wesley Signature Series (Cohn))
(4) Getting Value out of Agile Retrospectives - A Toolbox of Retrospective Exercises, Luis Gonçalves 和 Ben Linders
(5) Fifty Quick Ideas To Improve Your Retrospectives, Tom Roden ， Ben Williams

一般來說, 在進行 Retrospective 會議時需要注意以下事情

(1) 簡單

Retrospective 可以有很多進行的方式, 引導的手法可以千變萬化, 但是要記住這些流程都只是來幫助大家討論能夠順利, 能夠產生出大家有共識有用的內容. 因此, 不要把流程弄得太複雜. 有些時候會變成是 Scrum Master 在炫技, 在展示他引導的功力, 這樣本末就導致了.

(2) 專注

一般來說, 可以談要改善的部分真的很多, 你很難在這個有 timebox 的狀況下, 把所有東西都處理. 就算你可以都討論出一些做法, 想想你平時寫需求都來不及了, 就算有改善的行動, 也不容易有很多時間可以來落實. 因此, 你需要考慮一下, 在迭代 10% - 5% 的時間內, 你大約可以進行哪些事情. 集中火力把最重要的事情給做好.

(3) 責任共享

有些時候有些團隊會認為改善是某個角色的事情. 有些人會認為是 Product Owner 會幫他們把需求的問題給解決. 或者期待某個人會跳出來當出頭鳥, 把這些改善的工作給接去做. 如果大家都在這樣等待, 改善是不會發生. 必須要大家主動, 一起協同來分擔這些工作, 改善才能夠開始.

(4) 要有行動規劃

很多團隊在進行 Retrospective談得十分愉快, 因為在抱怨哪邊做得不好, 所以時間一下就過去了, 可以對於這些事情要怎麼處理, 卻沒有理出一些做法. 更重要的一點, 當這些做法有整理出來後, 需要再討論大家要如何認養這些工作, 以及大約在哪些時間點會有哪些產出. 這樣在下次 Retrospective, 我們就可以先報告上次的執行狀況. 沒有行動規劃和追蹤, Retrospective 容易就變成是清談, 團隊成員最後就不會對他產生任何期待.