The manifesto for agile software developement is often misinterpreted. To see what I mean take a look at "Agile vs Cowboy?" and the cowboy manifesto.

Waterfall projects usually landed up with heaps of documents, plans and designs but no working software. These heaps of plans can be quite expensive to produce and comes with this promise that the end product will be perfect because everything was thought out (which it rarely worked out according to plan). Agile software development addresses these problems by motivating teams to focus on completing working software and responding to changes as they come. But the concepts of continuous delivery, YAGNI and responding to change has been misunderstood as "the architecture will form itself over time".

The below debate between Jim Coplien and Robert C. Martin around TDD also touches on the place of architecture in agile software development. As an example, take note of Robert's comment at 5:16 that some devs think architecture is irrelevant in agile development. Although this is an old video I have experienced this mindset as late as 2018.

What happens with some so called "agile" teams is that they tend to do little to no planning/design for the following the reasons:

These beliefs come from a few key points in the agile manifesto:

Agile manifesto clearly states the importance of design and planning:

But keep in mind that agile design and planning looks different to how it was done in waterfall. You should not be designing and planning everything upfront because as the project progresses the team will learn more and more. The orginal design should be flexible enough for the design/plans/models/etc to change.

"you can improve a design by refactoring, and that you will do this often and rapidly. But past design choices make refactoring itself either easier or harder."

-Domain Driven Design By Eric Evans