I recall once developing a new module for an existing system in a more waterfall-like approach than one would expect nowadays and it actually worked out nicely.

I recall once developing a new module for an existing system in a more waterfall-like approach than one would expect nowadays and it actually worked out nicely. There were about 50 pages of specs for it: descriptions, wireframes for the UI, how everything should fit together and what the typical workflows with it would be. All of this was available ahead of time, before writing code even started, which actually let me get a better idea about the expectations and needs, than focusing more on immediate needs in a more iterative approach. I could also discuss any uncertain items and get some other questions answered, to avoid confusion later down the line. It helped me write the code better and anticipate how to structure things, so less refactoring needed to be done. I could also focus on the "happy path" first and foremost, getting the critical functionality in place and then adding the nice to haves around it. Admittedly, there were problems with the specs, which I brought up and promptly solved when it became relevant, so the final solution differed slightly, but by then the specs were also updated. With the critical stuff done early, it was also possible to release the thing early on and then switch to a more iterative method of development, with improvements and all. Not quite the traditional waterfall approach, not exactly scrum either, but something that worked nicely regardless. Complete specs (even an overview of the big picture) can definitely be a nice to have in some cases, if doing that additional planning at the start isn't too much of a burden. Take whatever works from all of the different methodologies out there.