想寫 Disciplined Agile 的緣由

在去年年底，我參加了一場敏捷相關的 Open Space 活動。沒想到，現場大家想討論的議題，依然和十多年前我剛接觸敏捷時如出一轍：老闆或 PM 不懂敏捷該怎麼辦？迭代一直被插單該怎麼辦？需求不斷變動該怎麼辦？

十年過去了，環境對敏捷的理解似乎進步了，卻又彷彿停在原地。

雖然時代在前進，現在大家都只關注要怎麼和 AI 聊天，但人與人之間的愛恨糾葛卻始終如一，只要有多人分工的情況，就還是得面對如何協同合作的議題。

敏捷雖然已經成了專案管理與軟體開發的顯學，有沒有「號稱跑 Scrum」甚至成了求職時的重要指標，但真正能成功落地敏捷的團隊又有多少呢？

「成也 Scrum，敗也 Scrum。」Scrum 的簡單讓人看本書、上兩天課就能開始在團隊裡推動，但這份簡單，是建立在去除了許多「非開發流程層面」要素之後的結果。那些被去除的東西並不會消失，反而會在導入 Scrum 的過程中慢慢浮出。

Disciplined Agile（DA）是更彈性、更務實的敏捷方法論。相比其他敏捷方法，DA 有兩個特別強調的觀念：情境導向和引導式持續改善。

從「沒辦法做到最好」到「基於現況做到最好」

在學習敏捷時，常被教導要先「傻傻地相信」，依循「守、破、離」的精神，照著所謂的最佳實踐一步步做就對了。結果往往是水土不服，不是被既有文化抗拒，就是遇到問題無法解決，還沒走到「破」的階段就已經在路途中陣亡。

有些團隊則為了妥協現實，客製化了 Scrum，卻因此陷入自我懷疑：是不是沒照標準做，才導致推不動？

Scrum 對敏捷而言確實是個很好的起點，但同時它也是終點。它能否順利運作，其實仰賴一個特定的環境和前提條件：開放且當責的文化、穩健的技術基礎、以及具備商業意識的團隊。如果這些條件不具備，強行導入 Scrum，只會讓問題不斷浮現。

所以 Scrum 一再強調，它不會解決問題，而是把問題攤開在檯面上，因為這些問題的本質其實就是現實與理想之間的落差。

當我們忽略現有環境的特性與限制，只為追求理想化的狀態而不斷引發出問題時，最終當然只會得到更多抗拒。

DA 的核心心態則更為講究實際：情境導向（Context Counts）、務實（Be Pragmatic）、並追求卓越（Be Awesome）。導入敏捷的心態不應該是「做不到最好只好退而求其次」，而是「在現況下盡力做到最好，並持續改善」。

這種從情境出發、循序優化的做法，才能減少衝突，提升導入成功的可能。

從「快速失敗」到「快速成功」

敏捷強調經驗主義，鼓勵透過小步實驗與快速失敗來學習。像是愛迪生花了兩年、累積了上千次實驗失敗的經驗，最終成功找出燈絲的材料。

但在現今瞬息萬變的市場裡，當我們還在反覆嘗試時，競爭者可能早已領先到無法追趕。

多數人能從失敗中學到教訓，卻不一定能從中摸索出成功的路。對多數人而言，盲目試錯只會耗盡信心。

就像學數學時，不會是直接丟出問題，讓學生自己想辦法推導公式，而是先教導理解公式的原理再做練習，因為這樣學習才會有效率。

Scrum Guide 只有十幾頁，許多未提到的部分並不會因為沒寫出來就因此消失。導入 Scrum 後，團隊仍得面對這些因為導入 Scrum 浮現的現實問題，只能四處找解法：教練技巧、引導技巧、利害關係人管理、DevOps、TDD、BDD、DDD…。

這還是團隊願意學習的情況，多數人最終只會得出結論：敏捷不適合我們，甚至敏捷是場騙局。

「從失敗中學習」固然重要，但「學會如何減少失敗、加速成功」更關鍵。能越快讓價值落地，延遲成本就越低，也能越早獲取收益。

DA 的「引導式持續改善（Guided Continuous Improvement, GCI）」提供了整個專案生命週期的流程目標，把那些「不知道要考慮」的環節納入思考，並搭配多種實務選項，讓團隊有方向地實驗與學習，降低風險，同時更快累積成功經驗。

「我只講重要的，其他靠自己想辦法。」
「我什麼都講了，你們乖乖照做就對。」

以上並非是在否定 Scrum，而是說明 DA 補足了 Scrum Guide 避而不談的部分。在什麼都沒有和什麼都規定好之間，提供了第三個情境導向且彈性的選擇。

DA 的工作箱就像一把瑞士刀，雖然功能繁多且不直覺，但當問題出現或舊方法失效時，它能引導我們嘗試其他選項，而不必束手無策。

雖然 Disciplined Agile 相對冷門，但正因它「什麼都要、什麼都可以」，內容龐大卻兼容並蓄。理解它之後，不僅能更好地推行各種敏捷方法，甚至也能改善傳統預測式專案的執行方式。

因為「選擇是好事（Choice is Good）」。