This is 100% anecdote, but IME agile doesn't work well enough to warrant "waterfall shaming" like this. So far, in 25 years of software development, the best t

This is 100% anecdote, but IME agile doesn't work well enough to warrant "waterfall shaming" like this. So far, in 25 years of software development, the best track record I've personally seen for on time and on budget was a big defense contractor that had a bunch of senior engineers and a relatively old fashioned waterfall process with some "extreme programming" and agile practices thrown in. It was documentation heavy and a hassle to think things through up front, but it reduced surprises later on, and the rigid documentation and process made it easy for different people to take over work at different stages of the workflow (requirements -> design -> coding -> testing) for each feature. It wasn't perfect, but it was predictable, and I never saw them toss features out at the last minute or deliver a half-assed release with a bunch of minor changes. And I'm sure the response to this will be a dozen people telling me all the companies I've worked for have done agile wrong, and then everybody will have a unique idea on how they should've done it instead... Agile might work great for CRUD websites, but it doesn't seem to work very well for other types of projects, and choosing something else seems reasonable. I guess my point is, even if these projects aren't "real" agile, I don't know if it's a real problem. The goal isn't to be agile, it's to get software developed.