Kruchten认为：敏捷注重YAGNI（你不会需要它）、重构以及把决定放到“最后责任时刻（Last responsible moment）”做，这些会带来重要决定做得太晚的风险。对于任何一个项目，总有一些需要尽早作出的关键决策，为正在进行的工作铺平道路——对于这些决 策，“最后”责任时刻事实上非常接近项目的开始阶段。
这些关键决策是驱动开发产品架构结构的决策。做出不好的选择（或者做出不慎重的选择），会导致系统无法适应不断变化的业务需求。选择有关系统的架构 结构，要在开发过程早期进行考虑。
他说：许多敏捷项目注重功能性需求（以用户故事表达），而忽略架构的方面，抱着不负责任的态度“我们可以以后再重构”，总是过于频繁地把“以后” 放在一边，直到为时已晚。
他举了一个例子：一个采用敏捷方法的金融交易系统。
用户故事已经识别好，发布计划以及开发工作已经启动。最初的几轮迭代取得了巨大成功——功 能交付了，客户参与度非常好，而且所做的功能完全符合业务需求。一旦有足够多的功能构成一个“最小的可行产品”，一个发布就会投入到生产环境中，而项目却 陷入了绝境——那些已经开发好的功能可以运行，但产品却无法应付实际环境中的交易量。客户不得不重新使用老的系统（还没有被关闭），而开发团队则回去重构 产品，以应付真实环境的需要——不幸的是，重构意味着不得不对大部分已经完成的工作进行彻底的重建，唯一可以利用的组件是界面设计。项目最终取消了，而客 户的组织非常不情愿再去尝试敏捷。
他并不是建议回去做大的前期设计，只是鼓励大家慎重考虑系统的重要质量方面，并确保架构特性同功能性故事一起考虑。架构特性是由产品的“非功能 性”或者质量需求驱动的——诸如性能、可靠性、容量、可维护性、安全性、可用性以及可测性等方面。这些方面会影响产品的架构——一开始就必须设计好它们， 而不是事后再去重构。
他承认取得进度的迫切需要——我们不希望开发团队花费1或3轮迭代，忙于“探索”对用户没有显著价值的东西。他认为，把架构需求编进产品的整体发布 计划中是可以做到的，确保在开发产品的时候，架构基础以及实用性功能都构筑起来，并且我们能够同时在日益增长的功能上，以及满足质量目标的能力方面取得进 展。因此，例如第一轮迭代可能只能看到一个单一的输入界面，但负载测试会显示系统的那部分组件，将能够应付生产环境的要求。
他提供一种方法，让工作变得可视化，并确保架构需求得到重视，而且与基于可视化的工作一起排列优先级——把颜色代码的概念应用到产品Backlog 中的各个条目中。
他说，backlog可能会有四种颜色的工作：
- 绿色——将要交付的功能特性，功能性用户故事
- 黄色——支持质量需求的架构基础
- 红色——确认好的缺陷，需要重视
- 黑色——开发产品过程中产生的技术债务，推迟的关键决策或者已经完成的劣质工作
