I see Waterfall as an unsuited methodology for software development. I see Agile as an improvement. In my experience, Waterfall does not work well because requirements are rapidly changing. Yes they are. Yes they are.

But they aren't always. Consider embedded development of computers controlling cars, or things like control software for radiotherapy. Bugs there can cost lives and the requirements are well defined, so full-blown waterfall processes are appropriate.

Moreover they aren't rapidly changing for all parts of a project. Usually with a little experience you can identify those areas where requirements are likely to change most. If everything else is well componentized, up-front design really isn't a bad thing. And if the components are small, iterations don't need to be long.

That's why subsidiarity is important, because it focuses on the design and development of small components by small teams, not big nebulous projects by very unstructured teams. A project may have a part of that but the more contained your rapidly evolving requirements are the quicker you can deliver them.