當Pattern遇到Scrum（5）：Sprint Retrospective

June 20 10:43~12:00

Sprint Retrospective Pattern

今天談Sprint Retrospective，簡稱Retrospective。該模式的原文在此，有興趣想詳讀的鄉民可以參考。今天看Context、Problem、Force、Solution這四個元素。

Context：Sprint即將結束，你已經準備好繼續打拼下一個sprint。無論這個sprint進行的如何，你總是希望下一個sprint能夠越做越好。

Problem：如何持續改善開發流程？

Forces：

• Daily Scrum提供了一個持續改善的機會，但由於每天周期太短不易發現改善之處也不易評估改善成效，加上Daily Scrum的主要目的在於讓團隊重新計畫以便達成Sprint Goal，所以不適合用來討論持續改善的議題。
• Sprint Review用來評估產品，且可能有stakeholders參加，同樣不適合用來討論持續改善的議題。
• Sprint一個接著一個，團隊傾向急著進入下一個sprint開發新的功能而忘了思索現有的工作模式可否有改善之處，因而導致相同錯誤一再發生。
• 團隊在最近一個sprint做了許多改善，他們認為現狀已經很好沒什麼可進一步改善，更多對於改善的討論只是浪費時間而已，他們的時間要拿來做「真正的開發工作」。
• 當團隊成員自我評量的時候他們可能會覺得不好意思、受威脅、不稱職，這可能導致防衛行為—否認自己的責任並且把問題歸咎於其他人。

Solution：在每個Sprint結尾舉辦一個活動讓Scrum Team可以評估它在Sprint中的工作狀況。

***

討論

Retrospective（自省會議）講起來簡單做起來不容易，畢竟持續改善本身就是一種「找自己麻煩」的做法，要讓團隊自我感覺良好很容易，要讓團隊自我感覺不良好卻很傷腦筋。因此不少人選擇「閉上眼睛就以為看不見」，或是抱持著「改善是Scrum Master的責任，你來告訴我怎麼做，我覺得合理就配合，覺得不爽就不鳥你」的心態。

落實持續改善最基礎的做法是讓Scrum團隊有一個大家共同願意遵守的Definition of Done（DoD），一開始DoD不要訂得太嚴謹，最好跟團隊現況一樣或稍微增加一點要求即可。隨著每個sprint的進行，依據團隊的狀況再逐次慢慢加強DoD。

另一種方式是在〈高效率Scrum團隊的九個模式〉介紹過的Scrumming the Scrum模式：「找出上一個sprint中最重要的一個阻礙（impediment），把它寫成user story加上驗收條件放入下一個sprint的sprint backlog，確保在下一個sprint結束前把這個阻礙移除。」

也有許多團隊喜歡每次retrospective採用一種新的開會方式，例如心情曲線與各種形式的ORID等。這些做法原意是讓團隊可以透過不同的角度來「自己看到問題」，但套用這些方法很容易走火入魔，變成為了方法而方法，流於形式而忘了原本目的是要持續改善。一開始團隊成員對於新的retrospective方法覺得很有趣，但是如果持續改善沒有發生，只有改善的方法持續改變，不久之後團隊成員也會覺得無聊而把retrospective視為浪費時間的活動。

很多時候持續改善無法發揮作用，並不是團隊不知道那些地方需要改善，而是團隊乃至於整個公司缺乏信任，因此團隊成員自然產生防衛心態。任何的改善建議都好像是衝著自己而來，不管是在檯面上還是檯面下，當然要抵死反對到底啊。

***

友藏內心獨白：實質重於形式。