根据设计倡导者西蒙·布朗（Simon Brown）的说法，软件设计的过程通常始于混乱的白板上，这种白板无法使任何人做好任何准备。是时候进行更多的前瞻性思考了。（banq注：敏捷团队围着一张白板画一些对业务粗浅理解，随着自己认识加深，这个过程会反复重来，学习理解业务的成本很高！成本高只好用加班时间抵充）
在敏捷时代，太多的软件设计人员害怕过度设计其应用程序。结果，许多软件团队放弃了架构思想，前期设计，文档，图表和建模。“在许多情况下，这是对过去繁重的流程臃肿的一种下意识的反应，而在其他情况下，则是对《敏捷宣言》的误解和误用。”
这就是开发人员软件体系结构的作者西蒙·布朗的话，他在Yow的一次引人注目的演讲中指出这点。在大会上，更多关于应用程序的思考被提升到软件创建的白板阶段。顺便说一句，他还不认可白板，并指出白板经常导致混乱或难以理解的草图。“作为一个行业，不幸的是，我们已经停止教授[软件设计]。如果您去问团队中的人'您如何设计软件？'，他们会迷迷糊糊地说，'好吧。 ，我们使用白板。” 您是否从白板上获得代码？您将白板用于什么？他们会说，“我们正在绘制图片，方框和线条。”
Brown孜孜不倦地倡导更丰富的前期设计规划，包括使用诸如采用统一建模语言（UML）之类的工具，这有助于为架构设计提供标准化和流程驱动的方法。他说：“更丰富的设计图导致了更丰富的设计讨论。” 团队成员和业务合作伙伴不必问诸如“该箭头是什么意思？”之类的问题。“这是Java应用程序吗？” 他说：“这是一个整体的应用程序还是一组微服务。” 相反，讨论应该集中在交付给企业的功能和服务上。
布朗说：“没有人谈论的是您必须进行设计才能进入软件版本1.0!” “您必须奠定一些基础，以便为迭代提供足够的起点，并在此之上发展。而这正是我们所缺少的。”
许多软件设计团队都将前期设计保持在最低限度，假设随着事情的进展，细节将在敏捷过程中充实。布朗说这是错位的思维，设计团队应将更多信息纳入他们的前期设计中，包括所提议的技术类型和语言。
大多数有关敏捷的文献说：没有大设计！。但是人们会错过'大'这个词，不是没有设计，而是没有大的设计！
同样重要的是：考虑到将敏捷宣言拼凑在一起的那些牛人（暗指Martin Fowler等敏捷宣言签署者）当时已经有很多从业经验，现在我们不可能拥有同样经验，环顾我们四周都是由相对年轻的人组成的团队；如果我们将这些经验丰富的敏捷宣言签署这从软件中剥离出去，带入他们到他们不熟悉的一个行业（banq注：让Martin fowler去做建筑设计、或做时装设计或做网页设计），他们还会谈论这些工作“只是实验和重构？”