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 t

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.