擷錄翻譯
常見的問題
- 我們的團隊很棒，我們沒有需要改進的項目…
- 回顧會議很無聊，所以…
- 我們實際的工作太忙了(或回顧會議太花時間了)…
- 我就不喜歡回顧…
你永遠不夠好到太好
作者舉自已經驗 10 年的團隊，每 2 周的回顧仍有許多改善的地方。
實際上你永遠不會好到太好，即便你已經是市場上最好的團隊。
在 VUCA 的世界一切都在變，就像一句老話說的「逆水行舟，不進則退」
看看世上最好的職業球隊，三連冠很棒，但是你試過四連冠、五連冠嗎?
再談談軟體的熵，為了滿足各種需求，你開始切前後端、開始用微服務
容器化技術、DevOps 到 SRE …
只會變得更細緻、更專業、更多的溝通…
所以真正的問題或許是，為什麼你覺得你不能更好了呢 ?
回顧會議很無聊
作者提供了幾個方法讓回顧會議回覆活力
- 由別的團隊的 Scrum Master 來帶領你的團隊的回顧會議
- 改變場地
- 使用不同風格進行
推薦書單 Improving Agile Retrospectives
尋求社群的建議，我個人再推薦一個網站 FunRetrospectives…
回顧會議很無聊對 Scrum Master 應該是個警鐘，
但是醫生也會生病，請勇敢的尋求協助，而不是僵化的照本宣科，
No one said a retrospective should be as exciting as the latest Hollywood blockbuster.But there are things you can to do to liven them up.
Too Busy To Improve
作者僅說明這樣是一個短視的團隊，
同時引用《高效率人士的七個習慣》書中的故事
短視近利的樵夫永遠不會打磨他的斧頭。
請注意「短視」的文化根歸何處 ?
這是一個複雜的問題，需要細心的觀察。
是團隊嗎 ? 或是 PO ? 也有可能是老闆或是客戶。
需要用系統思考的方式找到癥結點。
然後 — Change Your Company !
我就是不喜歡回顧
這個可能回顧會議變得無聊的變形
但作者將兩者分別出來的原因是，有的人就只是單純不喜歡而已
這些人只想作他們想作的部份…
作者例子基本上是團隊的害蟲了，
實務上我認為更多是人的價值觀不同，
在一般的開發人員或是 Team Member 身上或許還好解決，
透過溝通，排除他的困難。
個人經驗上比較麻煩的反而是中階主管，
比如說 : Team Leader 身兼 Team Member，
但是每次都翹掉回顧會議，說「我有其它會議、我很忙、我很特別…」
我的想法是將他的角色提昇到 StackHolder，如果他的權限會影響開發，
鼓勵他下放，讓 Team Members 具備獨力開發的能力。
讓他去作特別的事，反之如果他回頭想參與開發，
那應該與其它 Team Members 一樣全程參與會議。
黑暗兵法:在回顧會議取回他會影響開發的權限。喔，你當然可以選擇一場他不在的場次 :)
最後作者仍然補上可以減少回顧的可能性，
當你的團隊真得很棒，
或是為了讓回顧不無聊而付出巨大的努力，
或是你的團隊其實不太忙，甚至不太需要什麼改善計劃(可能要改善需求端)
能理解工作與喜歡作的項目的價值
團隊在一個極短的 sprint之中
可以減少團隊的回顧會議If your team:
Is really good.
Has made significant efforts to make sure retrospectives aren’t boring.
Is not too busy to invest in improvements that don’t pay them back immediately.
And understands the value of doing other than just the most pleasant work.… and if they work in short sprints, I’ll say it’s OK for the team do retrospectives less frequently.
但是並不建議，僅僅為了這個理由改變 Sprint 的長度，
而 Scrum Master 應該悍衛每個 Sprint 應執行的回顧會議，
但也可以適當調整為每兩個 Sprint 一次。
參考
- Does a Scrum Team Need aRetrospective Every Sprint?
- FunRetrospectives
- https://www.betteruserstories.com/courses/better-user-stories/videos?video_id=1
(fin)