很多團隊導入 Kanban 的過程長這樣：畫了一塊板子，分成 To Do、Doing、Done 三欄，站會時大家看著板子講進度。三個月後，板子還在，但流程沒有變快，老闆問「所以我們敏捷了嗎？」沒人答得出來。
問題出在哪？多數團隊把 Kanban 當成「一塊板子」，但 Kanban Method 其實是一套完整的管理方法。板子只是起點。那從起點到終點之間，有沒有一張地圖？
有，這張地圖叫 Kanban Maturity Model（KMM）。
▍KMM 是什麼
KMM 由 Kanban Method 創始人 David J. Anderson 與 Teodora Bozheva 共同提出，2018 年出版第一版，2020 年的第二版納入了為期一年多、在全球多家企業實測的 beta program 結果。
這個模型把 150 多個 Kanban 實務，對應到 7 個組織成熟度等級。它有三根支柱：
🔹 文化（Culture）：每個等級對應的文化價值觀
🔹 實務（Practices）：這個等級適合採用哪些管理實務
🔹 成果（Outcomes）：可觀察到的業務成果
重點在「對應」這兩個字。KMM 的核心主張是：實務要配得上組織的成熟度，太早採用進階實務會反效果。
▍7 個成熟度等級（附範例）
ML0 渾然不覺（Oblivious） 沒有任何結構化的協作方式。範例：需求用 Line 訊息丟過來，誰記得誰做，做完也沒人知道。
ML1 團隊聚焦（Team Focused） 團隊開始有板子、開始視覺化。範例：團隊有了 To Do / Doing / Done 三欄板，站會看板講進度。但每個團隊自己玩自己的。
ML2 客戶驅動（Customer Driven） 開始定義工作項目類型、設 WIP 限制、看基本流動指標。範例：團隊區分「功能開發」和「線上問題」兩種工作類型，Doing 欄限制最多 4 張卡。
ML3 符合目的（Fit for Purpose） 跨團隊、端到端管理服務交付，能對客戶做出可靠承諾。範例：客戶問「這個功能什麼時候好」，團隊能用歷史 lead time 資料回答「85% 的機率在 12 天內交付」。
ML4 風險對沖（Risk Hedged) 用量化方式管理風險與依賴。範例：用 Cost of Delay 決定哪個項目先做，而非誰的聲音大。
ML5 市場領導（Market Leader） 全組織持續改善，決策從上到下一致。
ML6 生存導向（Built for Survival） 組織具備持續重塑自己的能力，能在市場劇變中存活。
ML4 以上的組織非常少見。多數團隊的現實處境在 ML1 到 ML2 之間，而多數企業真正需要的目標是 ML3——能對客戶做出可靠承諾，就已經贏過大部分同業了。
▍兩種典型失敗模式
KMM 特別點出 Kanban / 敏捷導入的兩種死法：
⚠️ 好高騖遠（Overreaching）：組織還在 ML1，就想直接上 ML3 的實務。例如團隊連 WIP 限制都還守不住，就想導入 SLA 承諾與機率預測。結果是陣痛太大、直接夭折（aborted start）。
⚠️ 假山頂（False Summit Plateau）：導入 Kanban 後有了初步改善，就以為「我們已經做完 Kanban 了」，停在半山腰。開頭那個「板子還在、流程沒變快」的團隊就是典型案例。
這兩種失敗模式我在輔導現場都看過不少次。KMM 的價值就是給你一張等高線地圖：先知道自己在哪，再決定下一步走哪條路。
▍業界實際應用成果
兩個公開的案例：
📊 BBVA（西班牙對外銀行）：財務部門在 Teodora Bozheva 指導下進行了兩年的 KMM 導入，管理成本（management overhead）下降 28%。這個案例收錄在 KMM 第二版書中第四章。
📊 Vanguard（先鋒集團，全球最大資產管理公司之一）：24 個原本使用 Scrum 的團隊中，有 40% 在接觸 KMM 後主動改用 Kanban，而且這些 Kanban 團隊的流動指標幾乎全面優於 Scrum 團隊。這個案例收錄在 KMM 教練版的附錄。
誠實揭露：這兩個案例的數字都來自 KMM 作者本人出版的書籍與官方通路，屬於方法論提出者自己發布的資料，看的時候要記得這一點。不過 BBVA 和 Vanguard 都是願意具名的大型企業，這比匿名案例可信得多。
▍AI coding 帶來的調整
先說清楚：KMM 官方目前沒有針對 AI coding 出版對應指引，以下是我把輔導現場的觀察對回 KMM 框架的整理，屬於個人實務觀點。
AI coding 工具改變了一件根本的事：寫程式碼變快了，但驗證程式碼沒有變快。瓶頸從「產出」移到「驗證」。這件事對每個成熟度等級的意義都不一樣。
🔸 ML0–ML1：淹得更快 以前渾然不覺的團隊，工作堆積的速度受限於人打字的速度。現在 AI agent 一個晚上可以生出十個 PR。沒有視覺化，你連「堆在哪裡」都看不到。所以第一步沒變，還是把工作放上板子——但現在板子上要多一種卡：AI agent 正在做的工作。
🔸 ML2：WIP 限制要限的東西變了 以前 WIP 限制對應的是開發人力。現在產碼幾乎不占人力，真正稀缺的是人類的審查與驗證容量。實例：團隊的 Review 欄以前限 3 張卡，導入 AI coding 後 PR 產量變三倍，Review 欄爆掉。正確的做法是用 WIP 限制擋住上游——驗證容量滿了，就先不要再讓 agent 開新工作。工作項目類型也要增加一種：「AI 產出、待人類驗證」，因為它的風險特性和人寫的程式碼不同。
🔸 ML3：承諾的依據變了 lead time 的組成改變了——coding 時間縮短，review 和驗證時間的占比上升。如果你還用導入 AI 之前的歷史資料做交付承諾，會系統性地失準。要重新收集資料，而且要分開看「產出時間」和「驗證時間」。
🔸 失敗模式的 AI 版本 好高騖遠的 AI 版：團隊連基本的看板流程都沒有，就想全面導入 agentic workflow，讓多個 agent 平行開工。結果是一堆沒人看得完的 PR。假山頂的 AI 版：導入 AI coding 工具後 PR 數量翻倍，管理層以為交付變快了——但那是產出（output）變多，不是成果（outcome）變好。合併到上線的時間可能根本沒變，甚至因為審查塞車而變慢。
一句話總結：AI coding 沒有讓 KMM 過時，反而讓「先搞清楚自己在哪一級」變得更急迫。低成熟度的組織拿到 AI 工具，只是用更快的速度製造混亂。
▍資料來源
- Anderson, D. J. & Bozheva, T., Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention (2nd ed., 2020)
- David J. Anderson School of Management, KMM 介紹頁：https://djaa.com/kanban-maturity-model/
- Kanban+ 官方部落格（含 BBVA 與 Vanguard 案例摘要）：https://kanban.plus/blogs/blog/what-is-the-kanban-maturity-model
- Kanban Tool, The Kanban Maturity Model：https://kanbantool.com/kanban-guide/kanban-maturity-model
發表迴響