[你還在跑集體心理治療的 Retrospective 嗎?]

有些剛接觸敏捷的朋友, 看到公司在開 retro 會議
他好奇的問到這個會議有用嗎?
感覺好像是集體心理治療

我就詢問他說為什麼會有這個想法
他說到每次 Scrum Master 召開這個會議時
會用到不同的引導方法
像是 4L, ORID, 帆船法, Good/Could be better....
看起來 Scrum Master 好厲害, 引導功力好棒

可是每次會議都是在收集問題
雖然有些 action item
但是下次也沒有聽到那些 action item 的處理狀況
事情提了沒有被處理
這樣下次還有人要提嗎?
感覺只是每次讓大家宣洩一下不滿

就算有講一下上次 action item 的執行狀況
但是下次可能就在沒下文了
很多東西真的能改一次就好了嗎?
沒有持續討論改進, 真的會有成果嗎?

你們的回顧會議也是這樣嗎?

Scrum其實是一個倒吃甘蔗的工作方法
企業導入敏捷管理時常見的繆思就是以為可以提高工作效率，進而壓縮工作時間，或者以為 開發需求可以隨時更動，「但倒如敏捷初期其實加倍的工作時間，因為有很多會議要參與。」李佳憲笑著解釋，敏捷管理其實是經驗法則學習的管理模式，他靠的是實踐過程中的修正與調整所以靠著不斷的溝通，資訊透明度才會提高，團隊默契養成後進而可以減少溝通成本，更提高了市場驗證速度，進而產出有價值的產品或服務。

[Product Backlog Refinement 進行時機]

(1) 在 Scrum Planning 會議時進行 PBR
Scrum 在一開始時, 並沒有 PBR 這個東西, 所以便在 planning meeting 中去梳理需求. 但是這個會造成 planning meeting 開會開很久, 或許比較適合需求不太複雜的狀況

(2) 在 Scrum Review 會議時進行 PBR
Scrum Review 會議會展示這個迭代完成的需求, 所以也是一個合適的時機點, 來討論接下來下個迭代中的需求. 可是同樣會有的問題: review meeting 也會開很久.

(3) 在 Scrum Planning 會議之前, 另安排一個會議進行 PBR
專門有個會議在進行 PBR, 這樣可以讓 planning meeting 比較專注, 時間也比較可控. 但是不可控的還是需求要梳理多久.

(4) 在 迭代過程中, 依狀況召開 PBR
因為需求可能很複雜, 或者某些關係厲害人的時程, 需要在迭代中, 分成多次來進行. 通常是有需要時, 就召開 PBR 會議, 來梳理下個迭代中的某些需求

不知你們都是哪一種?