Client Runs on Waterfall

No, it shifts it, it does not replace it. Agile promotes the integration of what were, under classical Waterfall (courtesy of the DOD, in particular, codifying it) separate stages. Not separate in appearance, but actually separate. In classical Waterfall, following the DOD defined process which somehow escaped into the world, requirements, specification, development, and testing are separate stages possibly done by separate groups and executed in series. This is foolishness if it's a non-trivial project (on trivial projects you can use almost any process and succeed).

Agile is, in part, a counter to that foolishness: Those are not really separable things. You have to mix them for any non-trivial project. This means, if you're in a competent org, you do a mix of each of those activities (and others) throughout the development process, you don't remove them. At the start it's more requirements and specification heavy, with a bit of development and testing (prototypes, spikes in XP terms, and other things). As time goes on the process becomes more development and testing heavy as requirements and specification settle down, unless a real-world event makes the system obsolete before release. Then you figure out how to adapt to the changing circumstances which means revisiting requirements, specification, code, and test and figuring out what will surive, what won't, and how to make it work.

> A core Agile tenant is responding to change rather than following a plan.

That doesn't mean don't have a plan. It means don't be stupidly rigid, when the plan is overcome by events, respond to the events rather than stay committed to a now-wrong plan.

However, waterfall can be disasterous for the organization. If a single big iteration takes a year, the entire team might be building something worthless for an entire year without getting feedback that what they're doing is not what the users want. I've been on such projects.