傳統「瀑布式」的優點是階段清楚（先車頭再車身再車尾），流程明確、期程好估算；但缺點則是動線過長、週期過久，且對於市場變化較難回應，因為越往下，疊加的成本越高，改變也就越難（像「不可逆」的瀑布），最後更可能變成「做完就好」。
1990年代開始，世局變得更易變不確定、複雜與模糊（VUCA），各領域知識急遽暴增且迭代快速，相對於「I PHONE」的開發週期越來越短，課綱如果還是固定、規律地「10年擾動一次」，而且開發模式與週期仍然不變，勢必與現時社會產生更多衝突。
2030課綱開發可以向商業借鏡的地方，首先是核心團隊的組成。在業界，新商品的開發團隊，最少會涵括業務、設計、生產和銷售等四大部門的成員，避免業務接回來的單無法設計，或者設計出來的東西無法製造，或者製造好了賣不出去。在這方面，以往課綱開發團隊主要是以教育哲學學者為核心。
其次，開發模式可以參採「敏捷」，找出新舊融合的「最適模式」。
目前最被廣泛採用的敏捷框架是「Scrum」，原是指橄欖球賽中，當有一方輕微違例比賽必須重新開始的「列陣爭球」，雙方必須在短瞬間團隊以赴取得球權，後來就被軟體開發界用來代稱必須在短時間交付和維護錯綜複雜產品的開發模式 。
相對於傳統先車頭再車身再車尾的線性模式，敏捷是第一時間要先把模型車（概念車）做出來，這樣用一個「具體而為」的整體來跟社會大眾徵詢，比較容易獲得具體改進意見。否則只給我一個車頭，我實在不知如何置評。以致變成大家對個別車頭（理念目標）、車身（課程架構）、車尾（實施要點）的評價都還不錯，但整部合起來時，卻怪怪的。
更簡單說，過去的開發模式是先A再B再C再D，敏捷則是第一時間先出「微型abcd」，術語叫做「MVP」（最小可行性產品：Minimum Viable Product），藉以和社會明確溝通、蒐集具體回饋；然後在這個基礎上，重複「逐步完善與徵詢修改」的幾個循環，最後整體開發完成。
具體來說，以往的作法是，先花半年論述「理念和目標」，然後徵詢；接著再半年發展「核心素養」，然後徵詢....一直到所有部分完成。
敏捷模式，則是第一個半年就有一部「微課綱」，比如，如果初步提出「韌性」的課程理念（車頭），就一併把整車配套，包括「課程結構」增校訂、減部定；「學習節數」級距制；「教材編選」校本裝；教師員額、學生學籍鬆綁......等等都規劃出來。被徵詢者就可整全地檢視，是否真的有更多彈性機制來淬練韌性，以達成本次課改的基本理念。
先做模型出來是目前各行各業通行的產品開發模式，好處是讓社會大眾可以在真實情境與脈絡中參與及討論，獲得更具體可行的回饋意見，以幫助開發團隊繼續增生與迭代，逐步完善，終抵於成。
但是，這樣的開發模式，可能是開發過程就一直在吵，所以就需要一位「教練」（ Scrum Master）來協助開發團隊（Development Team）有效工作，這個 Scrum Master角色，也是以往課綱開發團隊所沒有的。但如果新課綱要在開發過程就積極、具體、深度和社會溝通，一定會對社會造成更大擾動（可是新課綱不就是想帶來新擾動？），此時就必須要有社會學家和社會設計專家加入團隊，協助精準設計參與機制，以進行衝突斡旋與完美溝通。
這樣開發出來的2030課綱，可能過程中爭議不斷，但完成時，卻可能已凝聚大半共識，而且因為廣泛參採各種真實意見，所以將會比較具體可行。
說穿了，課改其實是一種透過「社會擾動」來促成「社會革新」的「社會運動」，所以「吵」是一定的，因此「怎麼吵」就必須精準設計。過去是做完再來吵，但是吵了也沒用，因為已經沒辦法改，於是有人反抗到底。如果改成邊做邊吵，邊吵就邊改，然後做完也吵完了，這樣似乎是比較好的吵法。
所以2030課綱的開發，模式可以採用「敏捷」，過程則需要「社會設計」。
