分歧的一個主要原因來自於團隊如何工作，具體到他們遵循的是哪種開發方法學。如果從提倡多少預先設計來對常見的軟件開發方法進行比較，你會得到如下的圖。
一頭是瀑布式，它的典型形式是大型預先設計，推崇在開始編寫代碼之前，每件事都必須決定、評審和簽發。另一頭則是表面看來迴避架構的敏捷方法。
可以說這一點不是真的。敏捷方法沒有說「不做架構」，就像它們沒有說「不產出任何文檔」。敏捷是充分度、快速行動、擁抱變化、反饋和交付價值。但因為敏捷方法和它們的布道者不強調軟件開發的架構層面，很多人都將其誤解為「敏捷說不做任何架構」。更常見的是，敏捷團隊選擇把設計工作分散到整個項目，而不是全部預先做。對此有幾種說法，包括「演化架構」和「浮現式設計」。根據軟件系統的規模和複雜度以及團隊的經驗和成熟度，最終這可能不幸地演變成「盲目樂觀」。
兩頭中間的是像Rational統一過程（RUP）1 、規範敏捷交付（DAD）2 和動態系統開發方法（DSDM）Atern3 這樣的方法。這些是靈活的過程框架，實現中可以全部或部分採用。儘管RUP實現往往是與瀑布式方法有更多共同點的重量級怪物，它也可以縮減規模，呈現出能讓它佔據中心地帶的特徵組合。DAD基本上是一個精簡版的RUP，而DSDM Atern則是一個類似的迭代和增量方法，也受到敏捷運動的影響。三者都是風險驅動的方法學，基本上就是「集中主要的高層次關鍵需求，規避風險，然後迭代和增量」。DSDM Atern甚至使用術語「堅實的基礎」來形容這一點。做對了，這些方法就能在預先設計和演化架構之間達到良好的平衡。
1 http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
2 http://en.wikipedia.org/wiki/Disciplined_Agile_Delivery
3 http://en.wikipedia.org/wiki/Dynamic_systems_development_method