自省非自省

August 26 16:38~17:35

 

Scrum跑了一陣子許多團隊都會面臨「自省會議成果不彰」的問題。為了怕得罪人，有些人在自省會議變成「自我批判會議」，只提自己在這個sprint所犯的錯誤並且不斷道歉。有些人「有話直說」，不怕得罪「權貴」，例如在會議中直接挑明：「Product Owner所準備的user story太過模糊，害我們不斷修改程式浪費開發人員的時間。」

***

自省什麼？

Retrospective可以翻譯成自省也可以翻譯成回顧。自省並不是「個人行為的自我反省」，而是整個團隊針對「流程（做事情的方法）」的反省與改進。回顧這個sprint哪些做事的方法很好，鼓勵團隊持續維持。哪些做事的方式卡卡，找出最迫切的項目討論如何調整、改善。

鄉民甲：你們搞敏捷的人常說「自省會議是對事不對人」，但是事情就是人所搞出來的，討論到最後還會指涉到特定人士啊。

舉個例子，有團隊成員可能會覺得「Product Owner所準備的user story太過模糊，害我們不斷修改程式浪費開發人員的時間。」當腦袋想起這個念頭，其實已經對某個觀察到的現像作出結論了。換個角度思考，「不斷修改程式」是一個現象，但這個現象未必是因為「Product Owner所準備的user story太過模糊」所造成，也可能是因為開發人員遇到問題都不主動詢問Product Owner，導致程式寫好後才被要求修改。所以如果先描述現象，除了不斷修改程式以外，可能還有：

• 這個sprint開發人員認為已經完成（Done）的story卻不斷被移回到Doing狀態，或。
• 這個sprint原本預計完成五個story但最後完成3個。

這些都是開發過程中的「現象」，先溝通這些現象，接著再討論造成這些現象的可能原因，最後才擬訂改善計畫。

***

請ORID幫忙

有些敏捷團隊覺得在retrospective活動中使用「焦點討論法（Focused Conversation，又稱為ORID）」（請參考〈學問—100種提問力創造200倍企業力〉）可以避開「對人不對事」的問題。

• 客觀（O）：這個sprint發生什麼事件。
• 反映（R）：對這些事件的感覺如何，開心、喜悅、興奮、悲傷、生氣、暴怒、無奈。
• 意義（I）：這些事件背後代表什麼涵義？溝通不足、Product Owner太忙、團隊成員身兼多份工作、團隊成員遇到問題沒有立刻反應、不知道該如何反應、找不到人反應、不敢或不好意思反應、技術能力不足、團隊對於敏捷開發精神沒有共識、沒有定義Definition of Done（DoD）或沒有遵循它。 
• 決議（D）：把DoD印出來貼在taskboard旁邊，請每位團隊成員簽名；user story一完成立刻找Product Owner來驗收；sprint planning的時候讓團隊成員針對每一個user story撰寫驗收測試，拉近Product Owner與團隊成員對於user story內容的認知。

***

友藏內心獨白：Retrospective是持續改善的重要活動。