敏捷大師(Scrum Master)之所以稱為「大師」是有它的道理的,「大師」是那個能帶領團隊走對方向,並在敏捷路上愈走愈順的賢者、智者,絕非隨意指派,給個稱號就行的。
在《大錯特錯!敏捷大師不是團隊的助理或秘書》這篇文章中,我曾經概略說明了敏捷大師這個角色的職責、資格和等級,可是如果組織就是欠缺這樣的理想人選,那又該怎麼辦?有沒有什麼方法可以把「相對適任」的敏捷大師給生出來呢?
敏捷大師(Scrum Master)之所以稱為「大師」是有它的道理的,「大師」是那個能帶領團隊走對方向,並在敏捷路上愈走愈順的賢者、智者,絕非隨意指派,給個稱號就行的。
在《大錯特錯!敏捷大師不是團隊的助理或秘書》這篇文章中,我曾經概略說明了敏捷大師這個角色的職責、資格和等級,可是如果組織就是欠缺這樣的理想人選,那又該怎麼辦?有沒有什麼方法可以把「相對適任」的敏捷大師給生出來呢?
「老師,要管好專案的風險,您覺得是用傳統式的方法比較好,還是用敏捷式的方法比較好?」一位學員在課後向我這樣提問。
當下我還真楞了一下,倒不是因為我不會回答這個問題,而是自從教授敏捷相關課程這麼多年以來,這還是頭一遭有人問到這樣的議題。
先說我的結論,總體而言,我認為,敏捷方法比較技高一籌。
教授 Scrum 敏捷方法課程多年以來,不論是在公開班上,或是在企業內部裡,不論是被運用在專案管理上,或是被應用在整體組織的改造上,我發現,不少團隊或組織在施行敏捷方法的時候,經常有意或無意地把一些敏捷方法的重要設計給省略掉,誤認為這樣就能省掉調整組織規章、組織結構和人員心態等的大量心力,仍可輕鬆獲致敏捷方法宣稱的巨大成效。
組織營運或專案管理出了問題,企業對外找專業講師或顧問來協助,是直接、有效且客觀的方法,本無可厚非,不過我得說,如同人生了病會去找醫生一樣,病人如果不照醫生指示去定期服藥治標,也不願意花力氣去運動調整體質來治本,那麼,病好不了,無法根治,也就怪不得醫生和處方了,對吧?
日前為一家規模龐大的組織進行敏捷式專案管理課程,課前一天傍晚,副執行長熱情晚宴款待,席間提及,某個老舊資訊系統更新專案,執行兩年以來延誤不斷,掌握不了可靠的結案日期,令他相當頭疼,不過在他的話語之間,我倒是感受不到絲毫的怪罪之意!
副執行長雖然熟稔傳統式專案管理手法,但卻謙沖承認自己是敏捷方法門外漢,在我向他簡略介紹完敏捷方法之後,副執行長略顯無奈地提出了這樣的疑惑,「聽說敏捷方法可以把專案做得又快又好(客戶/用戶滿意),可是我們 IT 團隊已經用敏捷方法做專案好幾年了,這個專案還是延誤成這樣,不僅開發人力資源卡死在那兒,使用單位也抱怨連連,到底問題會是出在哪裡呢…」