在實施 agile /scrum 時, 大家都知道要有敏捷的文化很重要, 否則推行起來會事倍功半. 那要如何解決文化的問題? 這真的是一個很難的主題.
為什麼呢? 大多數敏捷的顧問或是專家, 雖然精通敏捷的各項技能, 但是對於處理文化的問題, 或者是人與人之間的互動, 還是無法琢磨太多. 一方面是清官難斷家務事, 另一方面他們也可能不是引導師或是變革管理的專家, 所以很少人, 或是很少文章談論這方面的主題.
最近在在網路上閒逛時, 發現到一個好玩的東西, 暢銷書 - Practices for Scaling Lean & Agile Development: Successful Large, Multisite & Offshore Product Development with Large-Scale Scrum 的作者Craig Larman 有提到一個定律: Laws of Organizational Behaviors
1. Organization are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structure
2. As a corollary (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo
3. As a corollary (1), any change initiative will be derided as “purist”, “theoretical”, and “needing pragmatic customization for local concerns” — which deflects from addressing weakness and manager/specialist status quo.
4. Culture follows structure
http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior
這一大段單字很多, 並不好翻, 我也不想翻, 避免限制了大家的想像. 但是可以用一句比較白話, 比較流行的句子來說明: "國民黨不倒 台灣不會好” (我只是比喻, 不要來跟我來政治筆戰)
也就是組織結構不改, 你就無法改變組織文化.
結構的問題, 真的嚴重影響工作的效率. 例如,
(1) 你組織如果是專業分工分明, 開發人員只做開發, 測試同學只做測試. 所以交棒的文件沒有就做不下去, 或者各自對同一份文件有不同解釋
(2) Feature team v.s. component team: 這裡要講很長的故事, 有興趣的可以去看這裡. 簡單的說, 元件團隊帶來低效率的軟體開發行為
http://www.featureteamprimer.org/
(3) 前端開發人員 v.s. 後端開發人員: 只有前端同學才能寫 UI, 後端的就不行. 所以每次專案進行, 就看到那少數的前端忙的要死, 但是後端的沒事做.
所以根據 Larman 的定律, 你可以有兩種做法
1. 改變組織結構
你需要對組織的結構做些改變, 這是硬碰硬的做法, 必須要很多東西配合才容易成功.
在我們公司, 大多數的測試人員是不寫測試自動化的, 而是由專職的 test developer 來寫. 因此在我花了不少時間, 招募到大多數的測試人員會寫程式, 因此才開始談所有測試人員都要寫自動化. 即使等到大家都寫之後, 也要到第二個專案後, 整個自動化的結果才讓大家很激賞.
現在我開始挑戰所有人員都要寫自動化, 包含開發人員, 期待也能有好的結果. 不過前提是我是所有人的老闆, 哈哈...
2. 利用一些工具讓大家知道目前組織的困境
像是利用 Kanban 這個方法, 從現有的組織結構開始, 利用視覺化和 WIP, 讓大家知道目前的困境發生在哪, 然後才來試著推動組織結構的變動.
這樣的做法是比較溫和的方式, 但重點是看到有問題後, 一定記得要處理. 很多團隊雖然知道有問題, 可是常常就沒下文了, 這樣就誰有救不了你了.
記住, 唯有組織結構改變了, 你的 agile 才有大效用, 否則沒多久就會被打回原形的. 切記!! 切記!!
留言列表
