分歧的一个主要原因来自于团队如何工作，具体到他们遵循的是哪种开发方法学。如果从提倡多少预先设计来对常见的软件开发方法进行比较，你会得到如下的图。
一头是瀑布式，它的典型形式是大型预先设计，推崇在开始编写代码之前，每件事都必须决定、评审和签发。另一头则是表面看来回避架构的敏捷方法。
可以说这一点不是真的。敏捷方法没有说“不做架构”，就像它们没有说“不产出任何文档”。敏捷是充分度、快速行动、拥抱变化、反馈和交付价值。但因为敏捷方法和它们的布道者不强调软件开发的架构层面，很多人都将其误解为“敏捷说不做任何架构”。更常见的是，敏捷团队选择把设计工作分散到整个项目，而不是全部预先做。对此有几种说法，包括“演化架构”和“浮现式设计”。根据软件系统的规模和复杂度以及团队的经验和成熟度，最终这可能不幸地演变成“盲目乐观”。
两头中间的是像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