敏捷框架的侷限

當年敏捷方法剛被提出時，許多團隊都抱著興奮的心情投入嘗試，彷彿只要導入 Scrum、開個每日站會、辦幾場回顧會，就能立刻提升效率、改善品質，甚至徹底改變整個組織文化。

然而，實際執行幾年下來，不少人開始發現事情並沒有這麼簡單。雖然敏捷的口號喊得響亮，但許多團隊卻陷入「形式上敏捷，實際上混亂」的窘境。站會變成了每日報告會，回顧變成了抱怨大會，迭代規劃根本只是重新包裝的專案排程。一旦規模變大或涉及多團隊協作時，更是問題叢生。原本強調自組織與快速回應的優勢也逐漸被官僚與流程取代。

敏捷之所以會在落地時遇到困難，往往是因為團隊只學到「怎麼做」，卻沒有理解「為什麼要這麼做」。Scrum 規範了流程步驟，但沒有教團隊該如何做出適合自己的選擇。Kanban 強調流程可視化，但沒有說明如何處理組織內部的權責問題。當面對實際環境中千變萬化的挑戰，例如跨部門合作、技術債壓力、架構決策或企業治理，多數現有框架都只能回答其中一小部分，甚至完全避而不談。

這些缺口導致許多團隊只能靠「照抄別人的做法」來嘗試敏捷轉型，缺乏根據自身情境調整的能力。更嚴重的是，一旦現成的做法無法奏效，就會讓團隊陷入迷惘，不知道問題出在哪裡，也不知道該怎麼調整。

許多人號稱導入了 Scrum ，但其實僅導入了流程，甚至還是變形過的流程。但真正卡住交付的，常在流程以外。

第一步就是分清楚：我們是「做事的方法」出了問題，還是「做哪件事、為什麼做、誰能拍板、用什麼技術做」有問題？如果方向、權責與技術基礎沒搞定，就算把每日站會、迭代、回顧都做滿分，也談不上真正的敏捷。

常見讓 Scrum 無力回天的瓶頸（開發流程外的因素）像是：

• 目標與決策：需求優先順序由職位最高的人決定（Highest Paid Person’s Opinion, HiPPO），自然也就無法專注真正有價值的事。
• 組織與獎酬：績效只看個人速度，大家各做各的，分工不協作。
• 架構與技術債：缺乏自動化測試能力，迭代後仍需要再安排時間做回歸測試。
• 人力與技能：關鍵能力缺口沒補，不停換手給新人，經驗累積反覆歸零。
• 依賴與治理：多團隊沒有整合節奏與版本策略，每個迭代都卡在等待。
• 預算模型：以個別專案形式編列預算，專案結束後就解散團隊，團隊穩定度低，無從談起持續改善。

結論其實很簡單：流程能讓團隊「跑得順」，但跑向哪裡、開什麼車、誰能換輪胎，決定了團隊能不能「跑得對」。先找出流程之外的關鍵瓶頸，再來調流程才會有效。

大型組織的挑戰與需求

當組織規模變大，原本簡單的敏捷做法往往開始失靈。Scrum、LeSS 或 SAFe 等框架雖然提供了清楚的操作流程與角色規則，但這些「標準答案」在實務中卻經常不敷使用。不同團隊面對的情境本就不同，各團隊可能分布於不同地區、屬於不同部門、使用不同技術堆疊，甚至承擔著完全不同的交付節奏與責任目標。這樣的多樣性，讓一套通用流程難以奏效。

更麻煩的是，許多企業導入敏捷時，並沒有根據自身狀況調整流程，而是直接複製別人成功的做法。結果就是團隊「被敏捷」：流程形式做得很齊全，但問題依舊存在，例如決策卡關、跨部門溝通斷線、缺乏整合策略等。這時需要的是一套更具彈性、能因地制宜的方法論，而不是一份死板的操作手冊。

Disciplined Agile（DA）正是針對這樣的情境所設計。它不強調「哪一套做法最好」，而是強調「依情境做出適合的選擇」。這也是 DA 能在大型組織中發揮價值的核心所在。

Disciplined Agile 的出現：整合與補足

DA 並不是一套空想的理論，而是來自現場實務的真實反饋與經驗累積。它的發展源自於長期協助大型企業交付與轉型的第一線觀察，例如小團隊使用 Scrum、Kanban 能運作良好，但一牽涉到跨部門協作、合規與治理、複雜架構與多系統整合，單一框架經常力不從心。

這個問題意識，正是 DA 兩位共同創建者帶來的養分。Scott Ambler 是前 IBM Rational 首席方法學家，長年推動 Agile Modeling、Agile Data、Enterprise Unified Process 等務實方法，強調方法應貼近現實。Mark Lines 則長期協助企業進行敏捷與 DevOps 轉型，在 PMI 併購 DA 後，也持續擔任推廣敏捷實務的顧問角色。兩人共同打造的 DA 並非一套「照著做」的標準流程，而是一套能協助團隊「做出選擇」的決策架構。

因此 DA 彙整了 Scrum、Kanban、XP、SAFe、LeSS、RUP 等框架的實務精華，發展出一個以「情境導向、決策為中心」為特色的工具組（DA Toolkit）。它不替團隊決定怎麼做，而是教團隊如何依照現況，選擇最適合的工作方式。

許多人初次聽到 DA，可能會誤以為它是 PMI 近年來才推出的新產品。實際上，DA 的雛形早在 2012 年就已誕生，當時稱為 Disciplined Agile Delivery（DAD），聚焦於軟體交付階段的實務挑戰。隨著應用範圍與顧問經驗逐年累積，它逐步拓展成涵蓋策略、治理、技術與文化的完整架構。

DA 的每一次演進，都是來自真實世界的回饋：從團隊層的工程實作，到組織層的資金模型與治理結構，都經過實戰驗證與不斷調整。這讓 DA 不僅是一套理論框架，更是一個可以落地實行的學習型系統，幫助團隊隨著情境變化做出持續改進。

從團隊敏捷到企業敏捷：DA 如何補上組織轉型的缺口

多數敏捷框架聚焦在單一團隊的運作優化，但當組織規模擴大，問題也從「團隊內部如何協作」，變成「多團隊如何整合」、「資源如何分配」、「治理如何一致」。這些問題，Scrum 與 Kanban 都沒有給出完整答案。

DA 在這裡扮演了關鍵角色。它不是單靠堆疊流程與角色來擴展規模，而是從根本提供一套可以跨部門、跨職能、跨層級運作的決策架構。透過流程目標（Process Goals）與選擇導引（Goal Diagrams），DA 協助每個層級根據自身情境調整工作方式，確保不同團隊之間能在共享的願景下，朝向共同目標前進。

簡單說，DA 幫助組織從「各做各的敏捷」，走向「整體一致的價值流管理」，真正實現企業層級的敏捷轉型。

結論：敏捷沒有過時，只是需要更成熟的進化

敏捷從來不是問題的根源，但也不是萬靈解方。它曾幫助無數團隊提升效率與品質，但當組織面對更複雜的挑戰時，原有框架自然會暴露限制。

DA 並不是推翻敏捷，而是延續敏捷精神，以各家的敏捷方法論為基礎，補充在實務上未曾解決的缺口。它提供一套彈性且務實的架構，協助組織根據情境做出適合的決策，進而持續改善、持續學習、持續交付價值。

所以，敏捷不是過時了，而是我們需要一套更成熟、更貼近現實的方法來延續它的價值。Disciplined Agile 正是這樣的下一步。

• About Disciplined Agile (DA)®
• Disciplined agile delivery