I also agree that well-run agile approaches throw big up-front design out. But I think they can happily achieve solid architecture and loose coupling.
There's nothing you can achieve with up-front planning that you can't achieve by refactoring your design after a release. The main differences are that you need some supporting practices to make refactoring economical, and that you have much more information available to you after release than you do before-hand.
There's nothing you can achieve with up-front planning that you can't achieve by refactoring your design after a release
If your application is relatively standalone then yes, but if you have heavy APIs and integration (which value adding applications usually do), you're up shit creek.
But I still think the way to good public server APIs isn't to sit in one's arctic Fortress of Architecture and think real hard. I think you just build and iterate in private, refactoring as you go, and then switch to a closed beta. And of course build your protocol in such a way that it's reasonably extensible.
Up-front planing is still no panacea. You will have to change your protocol someday. Someday soon if you're up to something interesting, because the world doesn't stand still. And even if it does, your competitors won't.
Agile doesn't work at all with large numbers of people on code that is constantly changing. Regardless of how you package it, the only way to achieve coherency and scalability of product development is through extensive planning, solid architecture and loose coupling of components.
Agile throws those three concepts out of the window for time to market. Sure your first few iterations will survive this, but as your product grows, so will coupling logarithmically. This eventually cripples you.