部門漸進式轉型敏捷團隊
【部門漸進式轉型敏捷團隊】
大家都有觀念也知道要漸進式變革，提高轉型成功的機會，尤其轉型面對的人數越多時，越是要一步一步踏穩前進，否則容易滑倒受傷。當然，如果已經到了生存關鍵時刻，那就需要大破大立進行變革。當然，這樣做的副作用也相對大。
雖然都知道要漸進，但要如何做呢?先簡單點，從同一個部門的層級開始思考就好。
假如，同一個部門近30人要轉型敏捷，你會怎麼漸進變革呢?或者是痛一次大轉型?
如果要一次大轉型，可能要先評估一下，部門會經歷的效能降低、幅度和成本，能不能承受的起?失敗的風險和轉型過渡期能不能接受?
以團隊發展模型來看，可能會有一段期間，團隊的效能降低50%，轉換成產出的話，價值可能會降低一半。
真的需要的話，可以參考規模化敏捷SAFe、NEXUS、LeSS...等等。這算是有系統、模式的變革，重要的是已經有前人的經驗為基礎，相對的也提高成功率。如果可以的話，最好是有經驗的顧問或教練帶著轉。因為就算是這些已經有一定方法、流程的大規模敏捷，還是有一定的前置準備要先進行。
像是，可能還要多個幾位敏捷教練或SM的輔助，角色、編制、組織多少都會影響，準備好後才能順利轉型。相對的，所付出的成本也會多些。
如果不要規模化，又該如何漸進變革呢?有哪些關鍵歷程必需經過呢?
如果沒有急迫性，又不必一次到位轉型的話，我們可以先從"需求源頭"轉型敏捷。再來進行執行開發層面的敏捷轉型，提供幾個其他想法參考。
情境說明：一個部門可能有30人左右(開發和營運)，想要進行敏捷嘗試。
步驟一：看板導入
先讓團隊習慣敏捷的一些文化和習慣，像是站立會議和回顧會議。不一定要一口氣全部導入，視團隊狀況選擇性加入，通常先針對團隊目前現有問題點去加強改善。
譬如說，團隊的開發狀態總是很混亂，在看板就可以引入回顧會議，持續追蹤改善項目。同時間，優化目前現有開發流程和工具。先把體質調整好，才能靈敏的動。
工作模式的轉變，有一個比較有趣的改變是，
過去大多是單人作業，敏捷元素加入後，多人合作的模式開始曾加，溝通的機會也變多。最常遇到的是大家不知怎有效的表達、理解。例如，Daily講不到點、Retro.痛點模糊說明，更不用說Planning一開始就要用Story來講需求了。
互動與溝通，也是需要點時間來練習、磨合，團隊在一致的頻道上，才能理解雙方的語言表達。
這階段可能會花個6個月左右，只要團隊都有持續進步改善，也不是絕對要用到SCRUM才叫敏捷。
導入敏捷不是價值，真正的價值是，團隊有好的產出才是價值。
步驟二：需求探索
通常有這步，大多是在產值上遇到瓶頸，已經不能再依靠幾個專業的營運或PO，就期望能創造出更高的價值。部門開始想要突破、創新，創造更高的價值。
這時可以導入設計思考、設計衝刺....等，必須靠團隊智慧來一起面對VUCA市場。
在這階段的第一個大挑戰是，
過往，團隊成員總是依靠企畫或營運寫好規格書，照著開發執行就好。
現在，一群人需要一起開會探索、討論需求，最大的困境就是不太會群體溝通。大多習慣於過去開會的方式，以檢討為主，而非創意。
這時的思考工具輔助就很重要，能有效的讓團隊一起發掘問題、共識方案，再進入開發階段。如果套用到SCRUM的話，這階段就是Planning meeting，但會更深入、更有目的、目標的定義需求。
團隊編制要如何調整呢?
以下提供幾個方式參考
方式1
從現有團隊成員中，挑選幾個人成立以創新為主的敏捷團隊。業務較獨立，但還是在同一個產品線內。利用短週期的迭代嘗試，找到產品可以更好的功能產出更多的價值。
團隊成員是多元且不需要依賴別人就能自己開發產品，更重要的是，團隊除了自身的專業技能有餘力外，對於需求有想法的會更好。Do the right things是這個團隊更重要的事。
方式2
專門成立虛擬的設計小組，負責找出更有價值的需求。
以往，可能都是由營運為主，但這個小組是跨職能，包含RD、QA、企甚至美術。集合大家對產品的想法，設計需求，再把需求任務給開發人員執行。
設計小組不負責開發，只要把需求探索出來發案執行，上線後持續追蹤成效，進行優化改善。
※結論
漸進變革的流程概念就是：體質→身體、四肢→心→大腦。
轉型前，要記得先評估團隊目前的成熟度(技術、工具、流程、心態)。如果基礎都還沒到位，或許要先花點時間把基礎做好(養好體質)，再來進行轉型。這裡的基礎指的是"做事的方法"。
當然，轉型不只是轉做事的方法，更重要的是心態、觀念的轉變，也是最容易失敗的地方。
心態、觀念都到位後，才有開始動腦發揮創意。因為這時候的你，已經全身投入，願意更投入心力在產品，讓團隊越來越好，自然而然就會形成自我組織。
8/2法則很好用，不管是用在組織還是個人，概念都雷同。在你還有餘力的情況下，拿出20%的時間去累積未來更好的成果。嘗試走出自己的舒適圈，讓自己更有價值。
留言
張貼留言