I'm at a loss to understand your "anything but Waterfall" mentality. Waterfall seems to be the only programming "methodology" [I hate the word] that pays anything more than lip service to the idea that software, like any other complex product, needs to be DESIGNED. And in my 34 years of computing experience, I've found that nothing leads to more productivity and responsiveness in a software project than having great design. Conversely, nothing slows down an IT department's response rate than having to deal constantly with the instability, bugs, and other difficulties that are inherent in poorly-designed or non-designed software.
For many years I successfully delivered very complex systems using a practice that I call "schedule-driven Waterfall". Every quarter the business agrees to the requirements for the coming quarter's development. After locking in something that can be reasonably designed and implemented in 3 months, developers proceed to build what was specified, with the first month of each quarter dedicated to pure design, and with no need to be shooting at a moving target. The business (or the client) may request changes at any time, but it is understood up front that no such "late" changes will be implemented until the following quarter at the earliest. The reward for this maturity? Quarter after quarter my clients got something that I've never seen delivered by any project using any other methodolgy: a thoroughly tested product with zero known bugs, and a near-zero bug incidence thereafter.
This process works but it requires discipline on the part of the business/client - i.e. the understanding that you simply cannot conduct a successful software development in an environment of continually changing requirements. It is an adult, real-world view based upon real-world limitations on what can actaully be done, and it requires the presence of grownups on both sides of the IT table. Which is perhaps why it will never be the fad du jour.
I read the Agile Manifesto, which supposedly defines the Agile mindeset, and it seems like some sort of back-to-the-60s hippie thing. "Individuals and interactions over processes and tools?" "Responding to change over following a plan?" "Customer collaboration over contract negotiation?" Yes and we're all going to have peace and love and get ourselves back to the Garden just because we want to. Right.
Sorry, I've been there, done that. Any project that isn't sitting on top of a great design and whose programmers aren't obsessively and constantly concerned with delivering great design is doomed to an eternity of low productivity.

Steve Yegge's scathing criticism of agile methodologies takes a page from Joel Spolsky's book. It's not merely an indictment of Agile, it's also a celebration of how his company does business. Just substitute "Google" for "Fog Creek Software" and you'll get the idea. It's a long post, so I'll ...