This seems to skip over the main issue I've had with waterfall - management picking dates before detailed analysis. So you get a nasty situation where the detailed analysis eats into your available time for the project.
This is mostly fine for people like UX, product or up-front architect types who don't have to deliver the software or deal with crunch time at end, but everything depends on what they spec out.
So, sorry, not sorry, I greatly prefer agile/incremental work to that.
Nothing wrong with management picking dates, as long as they understand that they're movable.
Find out that there's more work during detailed analysis? Move the dates or change the scope. Find something missed in analysis during implementation? Ditto. Find it during debugging? Ditto.
The problem isn't picking the date. It's the response to the date being wrong. (The date is usually wrong, unless you're in a domain that your team knows very well.)
And why do they respond badly to the date being wrong? Because they think the date can't be wrong. They expect it to be right. Well, if experience has shown us anything, it's that the date is wrong.
And this is what's wrong with waterfall. They take the initial planning as cast in concrete, as brought down by Moses from Mount Sinai on tablets of stone. It's not. The initial plan is written on sand. Acting like that is true is the difference between waterfall and agile.
> Nothing wrong with management picking dates, as long as they understand that they're movable.
Or the scope is flexible. This is basically why I prefer "agile" or incremental work. I'll do my best to work on the highest priority things given to me, one step at a time, and I'll leave no loose ends every week/month/etc that would prevent shipping software.
If we get to that management-picked date, the choice is theirs to determine if the product is good enough to ship.
This is the only way I've seen "scope negotiation" actually work. Otherwise you waste tons of time in meetings (while the clock is ticking) negotiating future hypotheticals, or product pushing you to cut corners writing tests or whatever.
Arbitrary deadlines also occur in agile scrum in my experience. Management says stop working on project X and start working on project Y. Project X backlog is effectively canceled and the product is in maintenance mode
> This seems to skip over the main issue I've had with waterfall - management picking dates before detailed analysis.
Yup. In Agile though, the opposite happens, we the devs are encouraged or coerced to agree to work tickets whose scope is not baked enough to start serious coding which should happen during planning or grooming...except raising a question you often get the "what part is not clear" condescending tone which discourages discourse and fleshing out of the ticket's scope.
This is mostly fine for people like UX, product or up-front architect types who don't have to deliver the software or deal with crunch time at end, but everything depends on what they spec out.
So, sorry, not sorry, I greatly prefer agile/incremental work to that.