The best architectures, requirements, and designs emerge from self-organizing teams.I have seen cases where I think some teams interpret this as good architecture emerges by itself as long as you follow good practices, e.g. XP, TDD, Scrum, etc. Caveat: I haven’t asked them…
This does not happen in reality. I have experienced colleagues who calls this a “manifested architecture” (every system has an architecture, deliberate or not), in a quite derogatory manner. The common problem with a manifested architecture is that it may fulfil all functional requirements (user stories, features, use cases, …) but does not really support any key quality attributes.
Good design, at all levels, are based on a vision of what the system should be, in terms of functionality/properties and structure. In a self-organised team this is hopefully a shared vision. You can appoint a single person to capture and disseminate this vision (commonly known as an architect), or you can use other principles to define and share the vision. The latter is my positive interpretation of the agile principle above. But you don't hope it happens without concious effort and don't do anything about it...
So how do you learn good design? The best (only) way to do this is to look at other good designs, with as much detail as available. This provides the “type of context dependent knowledge that research on learning shows to be necessary to allow people to develop from rule-based beginners to virtuoso experts”. (Bent Flyvbjerg)
