Scrum - 回顧。檢討？驗屍！

在Scrum方法中，每個Sprint結束要做事情是(1)實際交付產出 (2) 回顧檢討這個Sprint (3) 決定下個Sprint的開始。

其中，回顧檢討這個Sprint的做法，通常是一個2-4小時的Retrospective Meeting(回顧會議)，再加上改善動作。


實務上，回顧檢討是sprint最難做得好的項目。


困難因素在於，人類有天生的認知謬誤。回顧檢討會議既然是人來召開，人來組成，當然很難確切找到此Sprint的需要改善的問題，並對症下藥。偏偏，絕大多數專案Sprint問題和人有關。

說得更直白的：

    - 所有專案團隊的主要關鍵問題，都跟人有絕對的關係。每個sprint檢討會議不去檢討「人」，就等於是兇殺案發生而不去驗屍一樣。

    - 所有未來改善項目，其改善效果和速度，也都和人有絕對關係。

Scrum基本作法

在大部分的Scrum教學材料中(註1)，都很輕而易舉地說，團隊要在回顧檢討會議說，瞭解並討論三個項目：

(a) 這個sprint哪些地方團隊做得很好

(b) 這個sprint哪些地方團隊做得不好

(c) 下個sprint 團隊要做哪些事情使其變得更好



許多Scrum教學中，回顧會議都用一些簡單的方式：例如每個人提出3個意見，然後由Scrum Master逐一唸出，並且分類意見，接下來針對分過類型的意見投票，投完票之後再指定人選負責在下一個Sprint中改善。這個方式當然可以消除不少偏見和謬誤，但是容易忽略了「改善是需要針對人的行為而非針對事情」。


舉個某回顧會議中，團隊認為最需要改善的問題：

* 需求在sprint開始時還沒確定

這是個極為常見的sprint回顧問題，也通常是軟體團隊的困難。Scrum方法雖然試圖避免這個困難，但是還是非常容易在回顧會議中被提出來。筆者常看到會議記錄中，天真且單純的紀錄這一條問題....然後？也只是記錄而已。


這個紀錄有什麼問題？  ....有很大的問題！


大部分團隊，剛組成的時候，其Sprint檢討會議中，會不自由主的「避免」提出直接針對「某些人」的能力，做法，產出的問題。團隊會因為想要「努力團結」而避免針對人的討論。然而，除了超短期專案外，所有軟體專案，幾乎不可能「沒有人的問題」。反過來說，解決重要的人的問題，專案就會執行得更好。

回顧檢討要注重「人的問題」，並非單指某個人的能力不夠，也非某些人難以溝通。而是要透過實際的事物，探究人的行為造成的問題，而非問題的本身。「需求在sprint開始時還沒確定」是個血淋淋的事實。

但是，回顧檢討的重點在於，過去4周內，到底團隊成員知道是「誰做了什麼，或者沒做了什麼造成這個事實」，這才是重點。

正確的回顧檢討事實，可以是：


* 需求在sprint開始時還沒確定，因為Scrum Master沒有邀請Product Owner參加kick-off會議。

也可以是：

*  需求在sprint開始時還沒確定，因為Product Owner在kick-off會議沒講清楚，而團隊當時卻認為自己清楚需求，直到開始做了才發現不清楚，偏偏Product Owner之後就不參加每日例行會議。

也可以是：

*  需求在sprint開始時還沒確定，因為Product Owner在專案中間需求有改變，但是Scrum Master並未注意到大幅變更。

無論哪種回顧，都需要有「人」，「當時做的事情或這沒做的事情」，「產生的結果或沒產生的結果」。這樣的回顧檢討才會有意義。

但是，Scrum的方法論，看起來都是對事不對人。要如何在不交互指責的憤怒會議中，做到針對人的檢討，並能在下個Sprint還能持續團結合作？

如果你是專案經理或者Scrum Master，有三個基本的關鍵作法可供參考。(1) 先個人，再團隊。只內部，無外部。(2)  沒有問題，是最可怕的問題 。(3)實際事實，實際行為優先。

(1) 先個人，再團隊。只內部，無外部。

在會議開始之前幾天，先通知大家，回顧檢討會議的重點：先檢討自己，再檢討團隊，只檢討團隊內，不檢討團隊外。

(a) 先檢討自己的「行為」，再檢討團隊的「行為」。

並非要檢討個人的價值觀。例如，是不是很認真，很願意和其他人溝通...等等。而是自己先看自己過去做的「行為事實」，有什麼可以改善的地方。

例如：完成某功能程式碼之後，沒有先執行整合測試，就在某天每日會議報告已經完成，隔天發現，該功能有很多問題，還得修正進度，並且讓測試人員額外進行rollback。

另一個例子：這次sprint開始的時候，Scrum Master沒有堅持要Product Owner確定所有要完成的項目的需求，就讓Sprint展開。使得Sprint需要額外需求確認時間。

檢討團隊的行為，也和個人一樣。稍微不一樣的是，團隊行為通常是「個人行為」的組合。換言之，以「沒有人」為開頭的陳述就是團隊行為。Scrum Master或者專案經理，或者實際決定事情的主管，要特別注意，絕大部分的「沒有人」開頭的陳述，就要當作「自己」！

例如：沒有人發現在第二週自動測試的伺服器當機，連續好幾天的測試報告都沒有自動email出來，以至於團隊錯失及早修復bug的時間。

另一個例：沒有人提醒Product Owner開會的時間。

(b) 只檢討團隊內，不檢討團隊外

Scrum對於團隊有很嚴格的定義：做事情的人+Scrum Master = 團隊成員。

回顧檢討會議，必須要檢討內部，而不是檢討外部。許多檢討會議看似檢討內部，但其實是在檢討外部。

例如：加強和UX/UI部門溝通

這通常隱含對方不好溝通，我們只好努力跟他溝通。

又例如：公司有臨時交辦事項，團隊得分心處理

這隱含是更高階主管來的非專案任務，需要打斷專案時間。

這兩個例子並非不要改善。而是檢討回顧方式，會大幅「限制」或影響改善方式。與其他部門溝通問題，應該是具體列出過去4週，那些確切事情「被誤解」或者「理解錯誤」。根據實際的錯誤，來改變團隊對應的方法。

以UX/UI而言，釐清理解錯誤，可以用「雙方討論事情的時候，一定要至少要有mock-up」。

而以公司有臨時交辦事項為例。應該是「每個sprint預設的工作時間原本是160小時，下個sprint改為145小時，因為上個sprint臨時交辦非專案任務大約15小時」。這樣是以具體的事實，解決公司有臨時交辦事情的問題。

重點是：解決問題必須在「團隊內部能做的行為」，而非「希望團隊外去做的事情」。

會不會有回顧檢討的問題是「團隊內部解決不了」的事情？的確有可能，但是機率很低。團隊解決不了的事情，早就在sprint kick-off (開始會議)被隱含排除，所有團隊「認知到」的專案問題，幾乎都是團隊內部有方式解決或減少影響的。

(2) 沒有問題，是最可怕的問題。

有為數不少的專案團隊，在回顧檢討會議時，因為很多因素，無話可說。只好拿一些雞毛蒜皮的小事，或者看似重要但是不太重要的事情敷衍一下。

例如：

* 每週固定的下午茶太不健康，看能不能換健康一點的。
* 我們的螢幕太小，寫code很不方便。
* 每天站著會議好累，可不可以坐著
* 能不能有免費可樂
* 昨天code view有說code style要統一但是還沒有
* 我們可以固定一段時間來分享一下大家coding的心得

如果檢討會議的重要事項，全都是這類型的，那有三種可能(註3)：

(A) 團隊有如NBA夢幻一隊素質極高，工作合作超級愉快，成果驚人。

(B) 團隊失去對專案的信心和動力，或根本不相信Scrum Master。

(C) 團隊絕大部分的成員經歷太淺，不知如何開始檢討。



--- (A) ---

如果你認為你現在的團隊是A，大概有49.99%的機會你是在欺騙別人。另外有49.99%的機會是你自己騙自己，或被別人騙。


--- (B) ---

如果你認為你所處的團隊是B，而你恰好是Scrum Master，或者是專案經理，或者任何領導階層。那你最最需要做的事情是「檢討改善自己」，而非「檢討改善別人」。一個團隊，大部分的人不願意說真話，最有可能有問題的一定是管理階層。

如果你認為你所處的團隊是B，而你非管理階層，也非Scrum Master。你可以先審視自己專案對社會的重要性。如果你是在核電廠，或者急診室，那你應該盡自己一切的可能，不計代價，不眠不休地改善現況。

然而，如果只是一般的軟體專案，建議你先就自己可以改善的地方檢討自己。確定當你看到不正確的事情時，會先審視自己的能力與做法。但也不需要強出頭，把自己當作革命烈士。畢竟，大部分的軟體專案並不是那麼重要。


--- (C) ---

這種情況似乎也常發生，但是解決方法很簡單。

首先Scrum Master應該在第一時間對於「雞毛蒜皮小事」，做立刻回應。對於每個小事的回應都是：下次不用等到sprint結束，中間任何時候都可以馬上找我講。這樣才會讓團隊成員養成自動自發，並容易判斷哪些事情很不重要。

例如：

* 每週固定的下午茶太不健康，看能不能換健康一點的

...可以，馬上就換。以後一遇到這種問題，不用等到sprint結束，任何時候馬上跟我說或者寫信給我。

* 每天站著會議好累，可不可以坐著

...不行，因為站立會議的目的就是要讓你累。以後想到這類型問題，不用等到sprint結束，任何時候馬上跟我反應。

* 能不能有免費可樂

...可以，你馬上去買，發票給我。以後一遇到這種問題，不用等到sprint結束，任何時候馬上跟我說或者寫信給我。

* 我們可以固定一段時間來分享一下大家coding的心得

...可以，你馬上去發固定會議通知時間。以後一遇到技術分享的事情，只要不影響sprint時間，任何時候就直接去做，不用等到sprint結束。

(3) 實際事實，實際行為優先

Scrum的精神在實況與事實，而檢討的實況和事實在於「行為」而不在於「想法」或者「內心深處的感覺」或者「價值觀」。

這個概念非常重要。缺乏了這個概念，就容易讓檢討回顧會議，變成「互相責怪」會議。

然而，執行也很重要，執行不當，也會讓回顧檢討會議變成「互相責怪」會議。

首先會議一開始Scrum Master一定要強調，接下來的會議以事實優先，而事實當然是根據某人做的事情。在團隊成員互相不熟悉的情況下，要「反覆」的重述事實優先。並且在討論時，嚴守只看事實的承諾。

會議的形式此時就不太重要，不過：點名發表意見是個簡單的好方法。當然Scrum Master應該要自我拋磚引玉一下。

以下舉幾個常見例子：

成員J說：PM常常來叫我們改東改西，為什麼之前不確定好需求。

這時候Scrum Master應該列出這個sprint完成的task。追尋到底哪些task的需求被改變，大約影響了多少工作小時。
當然成員可能會說他不記得，就請他大致猜測一下。然後再跟sprint的時間做比對。如果改動所花時間很少，那其實不是問題。如果改動時間比率很高，才是值得關注的問題。值不值得處理，要看比率原則。-- (註4)

成員A說：我覺得我的task太多，都做不完。

這時候Scrum Master應該立刻請成員A把過去一個sprint做完的Task列出，看看是不是有做完，並且完成這些task是否有加班，或者，其實他的task是由別人完成，但是每日站立會議中並沒有說明？總之，現場應該了解事實，而事實也一定能被了解，不能等到「之後」。因為每個Sprint只檢討這個sprint，也就是過去4周左右，不可能需要很長的時間了解事實，也不可能有「我現在忘了要回去找一下」

成員K說：負責前端的人的bug太多，有時候負責後端的人都得幫忙修復bug。

這時候，Scrum Master應該立即根據bug清單，看看前端的bug數量，和負責解決bug的人。假設前端bug數量在過去sprint中有100個，而99個bug是由前端的人解決，有1個是後端的人幫忙解決，而且也只花了1小時。那麼這個問題根本不成立。只是因為後端開發伺服器的人，會特別記得「例外事件」就會有別人bug多太多害我多花時間的印象。這事情比例上多寡，是不是值得處理就要看「實際情況」列出判斷。一旦列出來給團隊成員看，就很容易大家一起判斷。

成員F：我coding速度是沒很快，但是有些速度更慢的人，就完成比較少的task，好像不太公平。

這時候Scrum Master應該根據git或其他版本控制系統，列出團隊成員程式碼數量。配合完成的task數量，bug產生數量(表示code品質不好) 以及bug解決數量(表示解決的問題)大約比對一下，看看團隊的產出是否「差不多」。當然，不同的作業系統，不同的平台，不同的程式語言是不能這樣比較。

不過大部分的情況下，這個問題並不會被提出來。但是，這個問題會存在在壓力比較大的團隊成員中，並且有礙於團隊成長。因此，Scrum Master自己必須要有客觀的衡量產出的方式！即便沒有人提出這個問題。

成員L：我們對所使用的open source工具不太了解，導致於需要學習的時間。

由於這個問題很具體，Scrum Master只需要確定這件事情是否還存在。下個sprint還會不會有不熟悉的工具需要使用。

後續？

 Retrospective檢討回顧會議中，如果找到重要的事項應該要改善。當然就是Scrum Master或者管理階層需要去「執行改善」的時候。前述內容都只有「找到問題」而關於如何有創意的解決問題，還請參閱後續文章。

---

註1：網路上參考資料非常多，例如：這裡，這裡 或者 這裡

註2：專案驗屍(postmortem)在許多人心中另有其定義，可以參考這裡，或這裡

註3：就只有這三種而已啊？確實有可能有別種，但是不太需要討論。例如：在某些軟體專案團隊的前幾個sprint，因為「蜜月期效應」的確真沒有大問題。也有很多軟體專案，本身的目標比較特殊：例如學校的畢業專案，或者政府國科會案，雖然要交付結果，但結果的本身根本不重要，當然也不有大問題。也有某些專案，並不適合採用單純的Scrum，所以無法使用檢討會議針對人進行檢討。

註4：Sprint的中途按照Scrum的精神本來就不能由PM/Owner隨意修改需求規格。但是，在這裡是Sprint的結束。如果Sprint中途真的發生臨時修改的事情，Sprint的結束當然要作為「事實」加以檢討。要注意的是，目的是檢討事實，而不是簡簡單單的說PM/Owner沒遵守「Scrum的規定」。Agile的精神中，團隊的溝通跟改善，遠比「規定」來的重要。由於軟體專案太常出現這類問題，所以後續文章也會有針對這種問題的建議解決方式。