如何舉辦一場產品回顧 / 檢討會 (retrospective)？

如果是有在跑 scrum 的團隊，應該對於 retro 這個詞並不陌生。在 scrum 這套方法中，每一個 sprint 結束後，團隊都會開一個回顧會議（也就是 retro，全名是 retrospective），讓大家一起討論有哪些做得好或不好的地方。此外，網路上也已經有很多 retro 相關資訊，甚至包含 retro 需要用的的模版都有了，可參考下面 2 篇文章：

敏捷方法的成功密技（十七）：想導入敏捷式方法，我該怎麼跟老闆溝通？

有些組織在嘗試導入 Scrum（讀音：「思逛」）敏捷式方法的時候，老是遭遇到一些奇奇怪怪的現象，效益也常常不如當初想像地那般美好，為什麼會這樣呢？有人說，那是因為 Scrum 敏捷式方法太過於理想化，太過於不切實際！可是，我們又該如何解釋那些為數眾多的成功案例呢？

敏捷方法的成功密技（十五）：未完成的用戶故事的進度怎麼算？

在運用敏捷式產品開發與專案管理方法時，我們知道，應該以「對用戶的價值」的角度來對工作（用戶故事 User Story）的優先級做排序（參考《能讓需求簡化，還能更省時、更省錢，提供更多價值，這…可能嗎？》一文），然後，將這些工作，「依序」安排到固定週期的各個衝刺（Sprints）去，並且盡可能地將每個衝刺都塞滿、都最佳化（參考《敏捷方法的成功密技（十一）：Scrum 如何最佳化利用衝刺的容量？》一文）。

敏捷方法的成功密技（四）：Scrum 的理想與現實的障礙

在上一篇文章《敏捷方法的成功密技（三）：Scrum如何擺脫「產品客戶不愛，團隊熱情不再」的窘境？》中，我們談到了Scrum架構可以協助「部份」解決溝通斷層的問題。若是想徹底一點改善溝通斷層的問題，則還需要把在更前端「產品定義階段的相關活動」也都納入Scrum的架構內來運作才行。除了流程架構這個「外功」，還有一個更為重要的「內功」，那就是團隊成員的組成。

敏捷方法的成功密技（一）：Scrum 為何對你很重要？

最近一位認識多年的朋友，讀完了Jeff Sutherland大師所撰寫的《SCRUM，用一半的時間做兩倍的事》之後，找我問了些有關敏捷方法的問題，我發現，大多數的人可能都把敏捷方法想得太過於簡單了，以至於在組織內施行的時候，到處碰壁。

專案中的「決策錯誤後悔厭惡」：如何克服因為擔心決策失敗而什麼都不敢做的心理障礙？

我這朋友平常做事都蠻謹慎的，這次想換車也不例外，他害怕買錯廠牌、害怕買錯規格、害怕買貴了、害怕未享受先折舊的損失，說到底就是「害怕以後會後悔」，因此研究一做再做，決策一延再延。買台兩三百萬的好車準備開個十年，這樣小心翼翼的決策方式沒什麼不好，愈晚下決策，通常也的確愈能買到更好更便宜的車款，不過，不管你任何時候做決策，決策之後的未來，肯定還是會有更好更經濟實惠的選擇，尤其是電動車這種技術和市場都在突飛猛進中的新產品。然而專案管理中的決策，卻萬萬不可如此。

這2件事沒做好，「敏捷式管理」將難以發揮功效

日前與前來邀課的客戶進行課程對焦會議，根據 IT 主管說法，IT 單位已自行實施敏捷式專案管理方法好幾年了，照理說，這個組織對於敏捷式專案管理的手法應該已經相當熟悉，可是不知道為什麼，卻還有這麼多的痛點，並且痛到下定決心尋求外部顧問的協助。我想，客戶的組織不是缺了兩個重要角色，就是這兩個重要角色因某些因素（如組織結構設計）而無法發揮應有的功能。