l

2014年1月23日 星期四

影響Retrospective Meeting成效的四個問題

Jan. 22 20:30~22:00

螢幕快照 2014-01-22 下午9.53.13

 

幾天前有一位朋友寫了一篇〈如何讓人在 retrospective meeting 說真話?〉的文章,內容很有意思,有興趣的鄉民們可以參考一下。讀完之後,Teddy想到有一次某個Scrum團隊的員工要離職,主管請Teddy以「外人的身分」跟這位員工聊一下。見面之後的第一句話,這位準備離職的員工就問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大家有沒有什麼問題?」而不是讓團隊成員將好的、有待改善的項目寫下來公開討論。

螢幕快照 2014-01-22 下午10.09.40

***

以上是Teddy觀察到影響retrospective meeting成效的四點常見問題,每一點都非常「致命」。要改善retrospective meeting的運作,Teddy覺得首先要從「培養給力的ScrumMaster」著手。雖然有人建議ScrumMaster不應該參加retrospective meeting,因為團隊成員想「公審」的對象有可能就是ScrumMaster。但Teddy覺得ScrumMaster還是應該參加retrospective meeting,直接觀察團隊成員的反應。

如果連ScrumMaster在場會造成團隊成員有所顧忌而「不敢講真話」,那這個Scrum團隊就真的是病的不輕。怎麼辦?快來報名Teddy的「Scrum敏捷方法實作班」吧。

***

友藏內心獨白:這一篇真的不是廣告文。

沒有留言:

張貼留言