I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these ste…
It's predictability.
You can plan the construction of a building, because the elements are known. If someone fails to deliver a bag of nails on time, it won't matter.
If you add labour to a project, it will very ballpark accelerate linearly.
1 team, 10 houses = 10 weeks, 2 teams 10 houses, = 5 weeks. Ballpark.
More developers do not mean the software will be finished more quickly.
There are economies of focus in software, generally not scale.
Which is why you want good developers.
The other factor is that 'Requirements Change' in Software more than they do in building, and that's the other #1 issue that causes problems.
The entire ethos of 'small releases, often' is built around that.
Software is evolved a big organically for this reason.
Waterfall is obviously counterproductive.
If there is a 'default' methodology in software it's 'Iterative Waterfall' whereby you break the project down into the smallest reasonable phases. There can be an overarching plan but it has to be nimble.