Реальная разница такая.

Waterfall - это контракт. Ты обещаешь конкретный продукт в конкретный срок за конкретные деньги. Заказчик подписывает. Дальше любое изменение требований - это допсоглашение с новой ценой и новым сроком. Заказчик это ненавидит, но зато у него есть иллюзия предсказуемости.

Agile - это отношения. Ты обещаешь двигаться в правильном направлении и регулярно это показывать. Заказчик получает контроль в обмен на свое время. Это честнее, но требует доверия.

Проблема большинства "Agile" проектов в том что они на самом деле не Agile. Менеджер хочет гибкость без потери предсказуемости. Заказчик хочет менять требования без последствий для сроков. Итог - ScrumFall: спринты есть, а реального управления беклогом нет, и дедлайны рисуются по Waterfall-логике. Это худший из двух миров.

Agile, без вопросов. Но учти один нюанс - внутренний заказчик это отдельная боль. Внешний клиент понимает что его время стоит денег и старается на встречи приходить подготовленным. Коммерческий директор будет считать что у него всегда есть право передумать, потому что "мы же одна компания".

Заранее пропиши в каком то документе (пусть это будет даже просто письмо в почте) как принимаются изменения требований и что они влияют на сроки. Иначе через 6 месяцев услышишь "мы же договаривались" - и никто не вспомнит о чем именно.

Waterfall не такой плохой как его малюют. Если бы вы потратили 2-3 недели нормально на сбор требований с комдиром, провели грамотный анализ и написали хорошее ТЗ - Waterfall вполне себе работал бы. Проблема не в методологии, а в том что никто не хочет инвестировать время в нормальный анализ. Agile часто выбирают именно чтобы не думать наперед - и потом удивляются что получился хаос.