Jan. 22 20:30~22:00
幾天前有一位朋友寫了一篇〈如何讓人在 retrospective meeting 說真話？〉的文章，內容很有意思，有興趣的鄉民們可以參考一下。讀完之後，Teddy想到有一次某個Scrum團隊的員工要離職，主管請Teddy以「外人的身分」跟這位員工聊一下。見面之後的第一句話，這位準備離職的員工就問Teddy：「我可以說實話嗎？」
Teddy不是該公司的員工，看起來也還算是「老實人」，對方就敞開心胸地說了許多內心話。經過將近兩個小時的長談，Teddy發現對方的鼻子並沒有變長，顯然應該是說出了真話
等一下，這不是一個Scrum團隊嗎？不是每個sprint結束都要開retrospective meeting嗎？有這麼多不滿，為何沒有在retrospective meeting提出來？很顯然是retrospective meeting出了問題。以Teddy的經驗，retrospective meeting進行不順利，大致上可以分成幾個原因：
- 公司文化大環境不鼓勵：不少Scrum團隊是在傳統command-and-control（一個口令一個動作）的企業文化之下，苟且偷生、苟延殘喘地運作著Scrum。團隊成員也許曾經努力地提出改善方案，但礙於公司規定使得改善的推行變得遙不可及。人都不是笨蛋，每次凝聚的改善共識都沒有落實，久而久之大家就不想動腦筋。retrospective meeting就算沒被廢掉，也變成沒有生命的行屍走肉，只是一個流程上不得不開的會議罷了。舉一個最簡單的例子，團隊成員都在還用3~4年前慢到不行的筆電在開發Android APP，嚴重影響開發進度。但「公司規定」電腦要5年以上，且有特殊原因才可以申請更換。在這種情況之下，公司層面想的是「預算控制」、「省錢」，哪管你開發效率好不好。反正效率不好都是人的能力不足，自己還不乖乖留下來加班，換什麼新電腦。
另外一個例子，Teddy以前有一個Scrum導入案的客戶，團隊苦於沒有足夠的測試設備可以使用，因此嚴重影響到團隊開發速度。添購這些設備其實花不了公司幾萬塊的經費，但是部門主管就是打死不想提出申請（可能是怕被老闆責怪，沒什麼績效卻一直在花錢），ScrumMaster與團隊成員也很無奈。
- ScrumMaster不給力：Scrum推行成敗與否，除了公司高層是否支持，還有一個很大的因素，就是能不能找到一位好的ScrumMaster。很多人會受到現況的制約，以至於畫地自限，不敢邁開大步協助團隊實踐改善方案。例如，以剛剛提到開發電腦太慢的問題。好的ScrumMaster就算知道公司規定5年才可以提出電腦升級，但只要電腦的速度影響了團隊開發進度，他會主動與公司溝通，對老闆「曉以大義」，讓他乖乖掏錢出來幫團隊換上最新、最快的「武器」。
- 團隊成員不長進：對，就是不長進。有些團隊成員已經習慣於command-and-control的管理模式，每天混吃等死，得過且過。要求他們動腦提出團隊做事方法的改善方案，簡直比登天還難。
- 以為自己在實施Scrum：有些團隊以為他們在導入Scrum，但其實只是新瓶裝舊酒，骨子裡還是用原本的做事方法與思維來進行開發活動。例如，retrospective meeting進行方式是由「偽裝成ScrumMaster的主管」詢問團隊：「這個sprint大家有沒有什麼問題？」而不是讓團隊成員將好的、有待改善的項目寫下來公開討論。
***
以上是Teddy觀察到影響retrospective meeting成效的四點常見問題，每一點都非常「致命」。要改善retrospective meeting的運作，Teddy覺得首先要從「培養給力的ScrumMaster」著手。雖然有人建議ScrumMaster不應該參加retrospective meeting，因為團隊成員想「公審」的對象有可能就是ScrumMaster。但Teddy覺得ScrumMaster還是應該參加retrospective meeting，直接觀察團隊成員的反應。
如果連ScrumMaster在場會造成團隊成員有所顧忌而「不敢講真話」，那這個Scrum團隊就真的是病的不輕。怎麼辦？快來報名Teddy的「Scrum敏捷方法實作班」吧。
***
友藏內心獨白：這一篇真的不是廣告文。
沒有留言:
張貼留言