Agile does replace requirement gathering and planning, though.

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

Agile certainly does not replace requirements engineering. The idea that it does, is exactly the problem.

Your customer needs to know what they want. If they don't, then it is way too early to start development.

If they know only part of what they need, agile can let you start on that, while your requirements analyst (or equivalent) helps them work out the next part.

What shouldn't happen, is a lot of random sprints chasing ephemeral ideas. That's just a waste of everyone's time.

But that's thing... your job as a developer is to help the customer figure out what they want.

> Agile does replace requirement gathering and planning, though.

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.

The agile manifesto does not reject planning. It just says adapting to change is more important:

"That is, while there is value in the items on the right, we value the items on the left more."

You still absolutely get requirements and plan. You just do it in smaller, more granular pieces.

What does requirement gathering and planning look like to you?