[PunchyHamster]

Knowing exactly what you want to build is pretty rare and is pretty much limited to "rewriting existing system" or some pretty narrow set of projects

In general, delaying infrastructure decisions as much as possible in process usually yields better infrastructure because the farther you are the more knowledge you have about the problem.

...that being said I do dislike how agile gets used as excuse for not doing any planning where you really should and have enough information to at least pick direction.

[reactordev]

If someone comes to you and says: "I want to build a platform that does WhizzyWhatsIt for my customers, it has to be on AWS so it's mingled with my existing infrastructure. It needs to provide an admin portal so that I can set WhizzyWhatsIt prices and watch user acquisition make my bank account go brrrrrtt. It needs the ability for my quazi-illegal affiliate marketing ring to be able to whitelabel and brand it as their own for a cut of the profits."

This is obviously satire but there's a clear ask, some features, from there you know what you need to have to even achieve those features, what project management process would you employ? Agile? Waterfall? Agile-fall? Kanban? Call me in 6 months?

[PunchyHamster]

Probably waterfall stuff that have actual clear functions and integrations (if you can extract all that system gets and what it does with it there is no reason to agile it) then slowly get thru the current mess, documenting it at each step while trying to replace it with something better.

Replacing existing system (and especially one you didn't write) is pretty much always the hardest case.