tl;dr: Some people seem to confuse the trait of a Software System having a good Architecture and a good Design with the activity of performing Architecture and Design explicitly up front and the role of an Architect and a Designer.
Most Agile Processes do not have a separate Architecture or Design phase, and they do not have specially designated Architects and Designers. Rather, Architecture and Design are emergent properties of the System and the team, and every member is equally responsible for good Architecture and Design. They do care about good Architecture and Design, which is precisely why everybody (not just one person) is responsible for it, and why they do it all the time (instead of just once at the beginning of the project).
This is like claiming that Test-Driven Development has no emphasis on tests, because there is no designated testing phase and no designated tester.
There is a common misconception that Agile means "never document your code, don't have processes, and never plan". This is wrong.
Here is what the Agile Manifesto actually says (bold emphasis mine):
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
It does not say you shouldn't have processes. Quite the opposite: it says that there is value in processes. It only says that if you must choose, i.e. if you don't have enough resources to implement both comprehensive processes and have rich interactions between individuals, then you should prefer the latter. Or, in other words: you should have processes that don't constrain interactions and individuals.
Likewise, it does not say that you shouldn't have documentation. What it does say is that if you have only enough resources to either deliver working software or comprehensive documentation, then you should prefer delivering working software. Which, I mean, is kind of obvious … what good is perfectly documented software that doesn't work?
The Agile Manifesto is augmented with Twelve Principles behind the Agile Manifesto, some of which I will quote here (again, bold emphasis mine):
Principles behind the Agile Manifesto
We follow these principles:
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Requirements is another thing that Agile processes are often accused of ignoring. But as you can see, the authors of the Agile Manifesto and its Twelve Principles have explicitly thought about requirements. And moreso, they explicitly acknowledge a fact that lots of other, "traditional" processes deny: that requirements change over time.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
This doesn't seem to have have anything to do with architecture and design directly, but think about it: if your development cycle is two weeks or even one (which a lot of agile companies actually do), then there is so little architecting and designing to do, that it may look from the outside as if you are doing none at all.
- Continuous attention to technical excellence and good design enhances agility.
Here you can see that design is definitely part of the agile mindset. Even more so: good design is important to stay agile! If you design yourself into a corner, where you can no longer change your code because it is so intertwined and brittle, then you can no longer move quickly (which is, after all, the definition of what the word "agile" means).
- The best architectures, requirements, and designs emerge from self-organizing teams.
Again, here you can see that the authors of the Agile Manifesto did not ignore architecture, requirements, and design, but explicitly included them in their considerations.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This is also a very important Principle that often gets overlooked. If you buy a book about Scrum / XP / Agile / whatever, and then strictly follow the book you are doing it wrong. If you discover that you could work better if you do a bit of architecture up front, then just do it.
Note also that Agile does not exist in isolation. In fact, several signatories of the Agile Manifesto are also signatories of the Manifesto for Software Craftsmanship, which is modeled after the Agile Manifesto and cleverly written as a sort-of "third column" added to the two columns of the Agile Manifesto (note that the first half of each sentence is directly from the Agile Manifesto):
Manifesto for Software Craftsmanship
Raising the bar.
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration, but also productive partnerships
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
I would argue that "well-crafted software" and to a lesser extent also being a "professional" includes good architecture and design.
Lastly, there is also the concept of Technical Debt and Refactoring.
The concept of Technical Debt means that, in theory, you know the most about how to correctly architect, design, and build your system, just after you have finished building it. As a consequence, this means that your system will not be perfect. It also means that if you want to build a perfect system, you are never allowed to start, because you don't have the knowledge how to build a perfect system.
Technical Debt, now, gives a way out of this dilemma: just like borrowing money to buy machines to make money to buy machines (financial debt allows you to move faster), Technical Debt allows you to start building your system with the best understanding you currently have. The difference between how you would have built the system if you had known from the beginning what you learned while building the system and how you actually built the system based on your limited understanding, that is Technical Debt.
However, just like financial debt, Technical Debt has to be paid back, otherwise you have to pay interest (in the form of more maintenance, harder to add features, slower innovation).
Refactoring is the tool we use to pay down that Technical Debt. Where Technical Debt is the difference between what you would have done if you had known everything you learned during the project from the start and what you actually did, Refactoring is the act of integrating that acquired knowledge back into the system, so that the system looks like you knew how to build it from the very beginning.
And that is where and when Architecture and Design actually, physically happens in Agile. Architecture and Design are discovered while building the system and integrated through Refactoring.