重大轉型是需要時間的, 尤其是大公司要轉型, 更是需要漫長的時間. 很多時候因為改革高層異動, 運氣欠佳, 或者改革團隊累了, 都會導致轉型功虧一簣.
通常我們會用近程勝利來保持大家的動力. 但是這可能也有反效果, 有時候會讓大家誤認為已經沒問題了, 導致性情鬆懈, 或者自己感到自滿, 使得傳統力量有機可趁, 最後導致轉型失敗.
就像減肥一樣, 雖然已經瘦了 10 公斤, 是一個不錯的開始, 但是重點這才是開始, 你還是需要不斷努力, 確保他不會復胖. 否則鬆懈之後, 你可能又開始大吃大喝, 又保持不動, 沒多久體重又回到原先重量.
因此, 我們應該持續在以下方面繼續努力
(1) 改革活動只多不少
如果已經有團隊或是部門導入敏捷成功, 應該開始轉向更多團隊去試行, 並且更多分享, 更多訓練, 更大規模的導入活動. 讓這個火力是持續並且是加強的.
(2) 更多協助
因為改革活動要變多, 自然需要更多人手來幫忙. 否則變革團隊會忙不過來, 輔助的品質會下降, 轉型就容易失效.
(3) 高層主管的領導
一個計畫需要有目標, 目標需要高層的認可和支持. 尤其為了避免轉型團隊因為近程勝利而鬆懈, 適時利用高層來保持大家的危機意識是必要的.
(4) 中低階主管加入主持
當要採用敏捷的團隊或部門變多, 轉型團隊除了增加人手外, 更重要的是要借用中低階主管來幫忙, 一方面他們是部門主管, 在推動中可以幫忙排除很多問題. 另一方面也讓他們有 ownership, 把轉型變成是他們的事, 這樣他們才會有成就感, 才會覺得這是他們的事.
(5) 去除不必要的相依關係
有時候有些部門或團隊不想推行敏捷, 其中一個藉口是所合作的部門或團隊不配合, 他們沒有 agile 我們怎麼有辦法 agile, iteration 這樣會無法配合. 這時候轉型團隊就要幫忙消除這樣的相依性, 或者是找到緩和的方式.
例如: 再找下一批要轉型的單位, 便可以以產品相依做考量, 有關連的盡量同時開始. 但是有時候不是這麼容易, 像是 UX 或是硬體部門, 他們可能天生不容易以迭代方式進行. 這時候你要如何提供業界的做法, 並且陪他們一起實驗, 找出屬於你們團隊的改良流程.
像我們公司老闆在推行 TLC (Trend Learning Circle), 想要我們公司變成學習性組織, 以系統化思考, 來促進公司整理的改進. 老闆很有心, 他知道不會一次就成功, 一次就有效. 因此他採取以下方式:
(1) TLC 1.0, TLC 2.0, TLC 3.0, 一段時間就演進一個版本. 讓大家不斷收到這訊息
(2) 一開始他自己教, 後來他就訓練高階主管來教. 讓更多助手來幫忙
(3) 一開始他請公司所有人來上, 後來便要求所有新進員工都要上, 確保知道這件事情的人不會因為員工流動而稀釋.
這就是鞏固戰果很好的範例.
另外, agile 的推廣就沒有像這樣有持續地進行, 可能是因為中間獲得了不錯的近程勝利, 讓高層認為我們已經很敏捷, 所以有點鬆懈, 忘記要持續下去. 因此這幾年導致有些部門舊勢力有大舉反撲現象. 雖然去年開始強調要導入 DevOps, 但是中間已經被反撲不少, 要再奮起代價可能很大. 另外, 有些新買進的公司, 因為錯過當年那段旅程, 後續沒人帶領, 因此並沒有敏捷轉型成功.
嗯, 轉型真的是件不容易的事 ....
上一篇: 敏捷轉型之天龍八部 - 創造近程戰果
全站熱搜
留言列表
