Overall Sprint Retrospective 是 LeSS 中特有的一個會議, 他並沒有 Scrum 出現. 它主要是討論組織內有關於跨團隊, 組織 和系統性問題.

圖片來源: https://seattlescrum.com/coaching

Overall Sprint Retrospective 的好處是, 它提供了一個機會, 讓各個 Scrum 團隊可以跨團隊協作, 讓大家一起合作解決問題, 不是只是某個團隊去處理. 這邊會希望團隊們可以使用 Causal Loop Diagram, 這是在進行系統思考時常用的工具, 讓大家把想法視覺化, 把可能影響的因子列出來, 並且思考可能相互影響的狀況. 而不是單純地認為做了什麼就會產生什麼, 這樣的單一思考.

參加 Overall Sprint Retrospective 的人員, 主要是 產品負責人, Scrum Master 和團隊的代表, 以及管理層 (如果需要的話). 之所以不是所有團隊成員參加, 理由應該很簡單, 就是控制會議的人數不要大爆炸. 這樣的會議進行才能夠有效率. 因為 LeSS 中人數遠多於 Scrum 的規模, 很多訊息的傳遞和溝通, 或者是和團隊之間的信任關係, 都會因爲人數變多而薄弱.

傳統 Retrospective 中, 產品負責人不是必要的, 主要是由團隊來主導改善. 但是在 LeSS 對於產品負責人, 是建議他需要出現, 因為產品負責人能帶來客戶的反應和回饋, 可以幫助工程師更了解真實世界. 另外, 傳統 Retrospective 把 PO 是為不必要參加, 某種程度這是一種證據, 它把 PO 視為非團隊的一份子, 有分化工程師和 PO 的嫌疑. Overall Retrospective 某種程度彌補這個狀況.

另外, 管理層在傳統Retrospective 中也是不參加的, 但是在 LeSS 中是可參加可不參加. 個人覺得 Overall Sprint Retrospective 主要是處理跨團隊, 組織 和系統性問題, 如果光只是團隊自己願意做外, 還需要管理層的協作, 這樣才能讓改善方案進行得比較順利. 所以會建議管理層能夠參加此會議, 了解團隊需要什麼樣的協助. 另外, 這也是一個機會, 試圖去培養出讓團隊成員們不會不安的管理層. 如果團隊成員老是不敢說話, 不敢說真話, 管理層應該要反思這個問題.

Overall Sprint Retrospective 進行的時間長度, LeSS 並沒有明確限制要多長, 但是依照 Agile 的慣例, 我建議還是有 timebox 比較有效率. 另外一個跟時間有關的是何時舉行 Overall Sprint Retrospective, 大多數人會認為在團隊 retrospective 開完後接著開, 這樣記憶猶新, 一鼓作氣把它解決掉. 但是也有一派認為, 在開完團隊 retrospective 已經是精疲力盡, 這樣的會議成果不是很有品質. 因此, 可能的解法就是把 Overall Sprint Retrospective 移到下個迭代中進行.

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

Overall Retrospective 可以討論哪些議題, 以下是我整理的一些常見的話題

(1) DoD 的改善
(2) 與組織流程或組織架構有關
(3) 與客戶合作有關
(4) 如何增強工程實踐
(5) Scrum 或是 Agile Practices 的改善

這些議題比較合適在 overall retrospective 提出, 因為單一團隊可能無法解決, 或者不該只是在單一團隊中發生, 或是只讓單一團隊去做.