上一篇講 ML0：連「需要流程」都沒有意識到的狀態。這一篇往上一級，講 Maturity Level 1，Team Focused，團隊聚焦。
KMM系列(2):我們哪有什麼流程，事情來了就做啊
https://agile3uncles.com/2026/07/25/kmm-level0/
先講場景。一個團隊來找我，開場白是：「我們有 Kanban 板，每天站會，也算敏捷了吧，但為什麼交付還是常常出包？」我去看了他們一天的運作：板子是真的，站會也是真的，平常日子運作得還不錯。然後我問了一個問題：「上次大 deadline 前一週，板子長什麼樣子？」
團隊安靜了三秒。有人笑出來：「那一週沒人在更新板子啦，全靠主管在群組裡吼。」
這就是 ML1。
ML1 的定義
KMM 對 ML1 的描述可以拆成三個重點：
協作變成習慣了。一小群人為了共同目標一起工作，而且是常態性的——這是跟 ML0 最大的差別。ML0 的協作靠運氣，ML1 的協作是每天發生的。
團隊開始理解自己的流程。每個成員還是各自負責自己的任務，但團隊對整體開發流程有了初步的認識，特別是知道流程從哪裡開始、到哪裡結束。
但一切還不穩定。團隊視覺化工作、每天開會確認狀態，可是流程還不一致，壓力一來就會失去紀律。績效幾乎完全依賴成員個人的努力和「那個人今天在不在」。
一句話總結 ML0 到 ML1 的躍遷：從「個人的板」到「團隊的板」。而 ML1 的天花板也藏在定義裡：焦點是團隊自己，客戶還沒有進入視野。
長什麼樣子？五個實際案例
案例一：平日很好，壓力下崩潰。就是開場那個團隊。平常板子有更新、站會有開，一切像模像樣。deadline 逼近時流程直接蒸發，回到吼叫驅動開發。這是 ML1 的正字標記——紀律是天氣好的時候才有的東西。判斷一個團隊的真實成熟度，要看它壓力最大的那一週，而非風平浪靜的日子。
圖 1：同一個團隊的兩種板——平常卡片每天移動；deadline 前一週板子凍結，實際進度轉入群組吼叫
案例二：一個人的球隊。團隊六個人，但誰都知道真正的引擎是資深工程師老王。難的卡他做、卡住的卡他解、上線他壓陣。板子上一半的卡最後都流過他手上。他請假一週，團隊產出接近停擺。KMM 描述 ML1 的用詞很精準：個人英雄主義（individual heroics）。老王是資產，同時是整個團隊最大的單點故障。
案例三：板子是給老闆看的。站會十五分鐘，每個人輪流對著主管報告進度，講完看主管臉色。卡片移動的時機是「站會前趕快更新一下」。這個團隊有視覺化的形，但視覺化的目的走偏了——板子的功能是向上交代，而非幫助團隊看見流動。形式上是 ML1，實質上團隊成員各自的工作方式和 ML0 沒有差別。
案例四：三個團隊，三種板，中間一條縫。前端、後端、QA 三個團隊，各自有板，各自運作良好。一個跨團隊的功能，在前端的板上叫「等後端 API」，在後端的板上排在下週，在 QA 的板上根本不存在。三塊板都很健康，工作掉在板與板之間的縫裡。這是 ML1 的結構性限制：每個團隊聚焦自己，沒有人看整條價值流。KMM 用「unconnected teams」形容這個狀態。
圖 2：三塊各自健康的板——跨團隊的功能在三塊板上有三種狀態，實際上掉在板與板之間的縫裡
案例五：非軟體版本——行銷團隊。五人行銷團隊，用 Trello 管理活動檔期，每天早上十分鐘同步。運作得比多數軟體團隊還順。但問他們「這檔活動對業績的實際效果」，沒人答得出來——工作做完就做完了，效果是老闆的事。做完（output）有視覺化，效果（outcome）完全在視野外。這同樣是 ML1：團隊把自己的工作管好了，服務對象還沒進入畫面。
先說句公道話
ML1 常被講得一文不值，這不公平。
從 ML0 爬到 ML1 是所有躍遷中改變最大的一步：從沒有協作意識到每天協作，從工作隱形到工作可見。KMM 也明確指出，ML1 是後面所有等級的地基——團隊要先理解自己的流程從哪開始到哪結束，才有可能在 ML2 把自己的工作看成「回應客戶請求的服務」。
地基的問題只有一個：它是地基，你要在上面蓋東西，而非住在地基上。上一篇講的假山頂（false summit）最常發生的高度就是這裡——有板有站會，看起來像敏捷了，就停下來了。
一個有數據的真實案例
波蘭有一篇 2024 年發表的學術案例研究，記錄一個中型企業的軟體團隊——先前導入 Scrum 失敗過——用 KMM 評估後定位在 ML0，然後按照 KMM 建議的順序逐步導入實務：第一個月補完 ML0 實務、加上 ML0 到 ML1 的過渡實務和初期 ML1 實務，逐月往上。三個月後，團隊的吞吐量變成三倍，軟體品質也明顯改善。
這個案例值得注意的地方有兩個。第一，它是研究者發表在學術會議上的獨立案例研究，而非方法論提出者自己的行銷材料。第二，它示範了 KMM 的正確用法：先定位（ML0），再按順序爬（ML0 → ML1），而非直接跳到高等級實務。連結放在文末資料來源。
當然，單一案例研究的結果不能直接推論到所有團隊，三倍這個數字也跟該團隊的起點很低有關。但「先定位、再按序導入」這個做法本身，是可以複製的。
怎麼知道該往 ML2 走了？
幾個訊號：
・團隊開始問「這張卡到底是誰要的？做完給誰？」——客戶開始進入視野
・有人抱怨「急件一直插隊，排好的工作永遠做不完」——需要工作項目類型和明確政策
・板上的卡越積越多，大家隱約覺得「我們是不是同時做太多事了」——WIP 限制的需求自己浮現了
注意這些訊號的共同點：都是團隊自己感覺到痛。KMM 的過渡實務設計邏輯就是這樣——製造剛好足夠的張力讓組織自己想改變，而非由上而下硬塞。等痛感出現再引入下一級的實務，抵抗最小。
AI coding 時代的 ML1
照例標注：這一段是我的實務觀點，KMM 官方沒有對應內容。
ML1 團隊導入 AI coding 工具後，上面五個案例會出現對應的變形。
案例二的變形：英雄的槓桿變大了。老王本來 carry 全隊，現在老王配上三個 agent，產出又翻了幾倍。看起來很棒？兩個問題。第一，單點故障更嚴重了——現在不只老王的知識在他腦中，連他怎麼下 prompt、給 agent 什麼 context、哪些產出他會多看兩眼，全部都在他腦中。第二，老王產出變多，下游要驗證他產出的人被淹沒，而 ML1 團隊沒有流動指標，根本看不到這個堰塞湖正在形成。
案例三的變形：站會裡沒有 agent 的位置。站會每個人報告自己的進度——但沒有人報告 agent 的進度。昨天讓 agent 跑的三個任務，兩個完成了在等 review，一個卡住了沒人發現。團隊的板子只反映人的工作，agent 的工作在板外流動。這在 ML0 那篇講過個人版，到了 ML1 要升級成團隊版：agent 的工作要上團隊的板，站會要走查它們，跟走查人的卡一樣。
圖 3：agent 的工作上了團隊的板之後，堰塞湖現形——堆積的位置從「進行中」移到「等待人類驗證」
案例四的變形：縫變得更寬。三個團隊都用 AI 加速自己的部分，各自的產出都變快了。掉在縫裡的東西掉得更多——因為每塊板的流速都上升，板與板之間的交接頻率也跟著上升，而交接處恰好是沒人管的地方。
講到底，AI coding 對 ML1 團隊最大的影響是：它讓「只看自己團隊」的天花板提早撞到。產碼加速之後，瓶頸移到驗證和整合，而驗證和整合恰好都是跨越單一團隊視野的事。以前 ML1 團隊可以舒服待很久，現在待不住了——這也算 AI 給的一份禮物，它逼你往 ML2 走。
資料來源
・Anderson, D. J. & Bozheva, T., Kanban Maturity Model（ML1 定義出自書中 Understanding Kanban Maturity Levels 章節；beta 版節錄：https://res.infoq.com/articles/book-review-kanban-maturity-model/en/resources/KMM_Excerpt_InfoQ-1524573067668.pdf）
・Ossowska, K. 等，Impact of the Kanban Maturity Model on a Team’s Agile Transformation（2024，Springer LNBIP 學術案例研究）：https://link.springer.com/chapter/10.1007/978-3-031-61154-4_7
・五個團隊案例為作者輔導與觀察經驗，細節經過改寫去識別化；文中三張圖為示意圖
發表迴響