我認為整個 Scrum 架構中，對系統以及最終的自組織目標，最重要、最有價值的一場活動，就是檢討會議 (Retrospective)（後簡稱 Retro)。但是，Retro 也是我認為最難開，最難主持的的活動。常見的低效益 Retro 有以下的特徵：

1. 熱烈的討論公司與產品方向
2. 成員們輪流互相感謝
3. 針對 Sprint 遇到的問題，制定新的工作規則

本篇不深入的探討如何進行 Retro ，網路上有很多大神的文章已經鉅細靡遺的闡述過這個主題，自忖寫不出什麼新意。我從管理的角度，來討論為什麼上面描述的特徵會帶來低效益，以及改善建議。

討論公司和產品方向，錯了嗎？

除了兩次不好的職場經驗外，有三個讓我尊敬 CEO，都有一個共同的特色：樂意聆聽團隊成員的意見，並鼓勵大家思考。所以，這個命題的答案並沒有錯，有問題的是討論的場合和心態。

Retro 既是 Scrum 開發系統（流程）的一環，它的討論重點就應放在系統／流程本身。Scrum 的遠景在於將團隊發展成「自組織」(self-organization)，在「系統思考」一書中，有這樣的描述：

系統通常具有自組織的特性，具有塑造自身結構、生成新結構、學習、多樣化和複雜化的能力

Scrum 團隊系統要發展成高效、成熟的自組織，在 Retro 中討論公司與產品方向，顯然無法達成目的。黃大米有一篇文章「月薪沒有 20 萬，你真的不用操煩到公司營運」，常常被我拿來當作自我警剔的工具：

• 我對這個議題有話語權嗎？
• 我目前被交付的任務是制定公司策略，還是落地執行？

這是角色與責任（R&R）的基本認知。在錯誤的場合，用錯誤的 R&R 認知進行公司策略等級的討論，訊息缺乏向外傳遞的「介面」，久而久之，團隊成員容易落入一種「說這麼多幹嘛，反正老闆也不會聽」的低潮情緒；而且，在缺乏充份的市場、經營資訊下的討論，也難以形成改變公司決策的提案。

我的建議是：透過在 Retro 中有效的引導，讓團隊不斷的針對系統／流程問題進行修正，進而形成互信、默契與文化，才是培養自組織團隊的正確方式。

對夥伴充滿感謝，錯了嗎？

暢銷書「被討厭的勇氣」裡面提到：人在被感謝的時候，會明白自己對他人有貢獻，進而感受到自我價值。因此，這題的答案，依然是：沒錯。但問題在於整場 Retro，大部分的時間在互相道謝，對系統／流程面的問題討論很少甚至沒有，就是大問題。

通常會發生這樣的狀況，是因為團隊不知道該討論什麼議題，所以用大量的互相感謝來填補沉默的尷尬，但又很容易落入針對團隊成員的本份進行感謝，我認為是多餘了。感謝的藝術在於「覺察」。如果我們可以發覺某個夥伴，為了合作順暢，用心與創新的做了巧妙的設計，且提升了團隊效能，我們明確又即時的給予回饋，會最大程度的給予夥伴成就感與提升在團隊中的自我價值。

舉例來說，走味的感謝：

「這個 Sprint ，設計師有準時把圖都出好給我，讓我也能準時交付，感謝設計師」

「QA 幫我抓到 xx 個 Bug，讓我在交付前可以修正，真是太感動了」

帶來價值的感謝：

「這次的設計文件，設計師貼心的幫我點出了 xx 元件會在之後的 xx 畫面中使用，讓我可以朝模組化的方向去設計，節省了我下次的開發時間，對我幫助好大。」

「QA 這個 Sprint 在開發前，特地提醒我他在之前的經驗中，發現某處要小心 xx 可能的問題；有了這個提示，我在開發中特別留心，發現真的如此，進而做了 xx 設計，讓我這次的開發的品質提升了」

好的感謝，除了帶來自我價值的肯定外，也能讓其他的團隊成員了解：「原來，這樣做，就可以幫助到整個團隊啊！」以此形成一個積極向上的正向循環。

制定規則，錯了嗎？

在以生產為主的企業中，有一個專有名詞：稼動率。意思是設備在所能提供的運轉時間，為了創造價值而佔用的時間百分比。為了提供生產效率，操作設備的工程師或作業員就必須減少錯誤的發生。人類的判斷充滿了雜訊，為了避免現場業人員的判斷出錯，就必須制定規則，或是標準作業流程。一旦面臨標準作業流程規範外的狀況，就必須停下來，由更高層的主管在作業流程中新增規則。現場人員無法自行決定如何排除問題，這就是所謂的無法自我修復的系統。

在腦力密集產業，產出與時間，無一定的正比關係。我們需要的是彈性與啟發創造力的環境。訂規則固然是解決協作問題的最小阻力之路，但時間一長，我們就會發現到疊加的規則愈來愈多，然後就忘記了。

有什麼事情是不能每天在站立會議上溝通一下就解決的呢？廻避溝通的團隊，就算有再多的規則，也無法成為 A team。我是建議是：放下規則，擁抱原則。

有關高效檢討會議的開法，「精實咖啡」（Lean Coffee) 是一個非常好的會議框架，可以看看這篇文章。最後再提醒一句：打造自組織，從充份利用 Retro 開始。