很多公司, 很多團隊在推廣敏捷時, 付出了很多時間和資源, 可是效果卻不盡人意. 我相信這樣的狀況, 很多人都有遇到, 問什麼會這樣呢? 是 Scrum 或 XP 不好? 還是推行的人有問題?
Kanban 方法的發明人, David J Anderson 在一次訪問中, 對這樣的事情, 提出了以下看法:
根本問題是因為人們對變革, 有天生的牴觸情緒. 尤其是企圖在嘗試大型企業中，向數以千計的員工推廣, 你將會面臨許多的抵制. 我聽過幾乎每一家試圖實現大規模敏捷流程的, 都遭遇過這種抵制, 很快地這個專案就宣告失敗. 有趣地, 公司仍然不放棄, 又再進行這樣活動, 可惜幾次都是以失敗收場.
Odd-e 呂毅教練也說到, Scrum 的有效運作需要組織設計, 所以第一步會是改革. 看板方法尊重現有的組織結構, 從現狀出發, 因此他的第一步比較是改善. 引入過大的變化, 自然產生的挑戰也會很大, 結果往往適得其反. 但是, 如果過於保守, 而引入過小變化, 會使變化過於緩慢, 也可能逐步喪失了改革的能力.
所以敏捷領域的最大難題, 在於人們抵制變革, 從每年 VersionOne 的調查 (http://stateofagile.versionone.com/) 中, 可以明確地知道這件事情. 所以你要做的, 不是只有精通敏捷的做法, 更重要的是變革管理, 如何以漸進變革的方式, 讓人們知道自己有問題, 願意嘗試新的做法.
尊重現有狀況
Scrum 一開始帶入三個角色, 並且以迭代的方式進行. 對 PM 或是經理來說, 他的職位不保, 對團隊成員, 則是做事方法大轉彎. 即使 scrum 立意良好, 也很難讓大家容易接受. Kanban 採用變革管理的做法, 一切從現有制度開始, 藉由曝露問題著手, 有痛才改, 讓改革變成是理所當然.
眼見為憑
很多人都是眼不見為淨, 沒看到真的有問題, 就不知道事情很嚴重. 因此看見是觸發變革的第一步. 看板方法的 core principle, 第一條就是強調視覺化, 讓大家知道有多少工作要做, 每個人負責多少事情, 哪個工作已經拖延很久, 或是哪的階段已經堆積很多事情了. 藉由資訊視覺化, 讓事實說話, 而不是個人喜好.
非只有開發團隊可用
看板著眼端到端的價值流, 改善IT與業務的協作, 並且也整合後段部署的工作. 讓業務, Devops, 以及不同團隊 都可以利用看板方法來管理. 不會像 Scrum 或 XP, 被人感覺只是給開發團隊使用, 其他人的工作就無法加入. 像下圖中, 前面將 PM 想法的處理, 也放到看板上追蹤處理. 這樣我們就可知道, PM 的點子, 落實了多少, 哪些已經被做了, 哪些點子 ROI 如何.
因此, Kanban 是一種完全不同的提升敏捷性的作法, 以演進的方式來實現敏捷, 把對變化的抵制降到最低的限度, 以提高敏捷導入的成功機率, 這就是我們需要它的原因.
心動了嗎? 想要了解 看法方法嗎? 可以參考以下密技, 省下你寶貴時間, 讓你加速進入敏捷的世界.
全站熱搜
留言列表
