It is difficult to explain to a division director that they do not have sufficeint capacity (enough qualified programmers) to compete features within a set time budget. The old joke goes, "It takes one woman nine months to produce a baby. But: what if we just put nine women in a room for one month!?"
In my professional consulting experience I've found most of those purported "hard deadlines" as mentioned above were usually arbitrarily defined, in other words: completely made up.
Yeah that never gets old. But it may be some features can be delivered in stages, maybe some can be solved other ways than intended that require less work.
If the org focuses on the customers one can work together to find a way.
What has happened to me in those cases is that Architects lumped on a lot of extra nice to have things which would certainly have made us fail the time constraints. It was completely un-agile and I only got things done on time by demonstrating very clearly that time sensitive work is not the place for grand refactoring and at last winning over the main architect.
When there's a time constraint one has to be able to winnow out the real must-haves from everything else.
Right, that's deadly. We try to do small refactorings when we can, but for hard deadlines everyone is reminded to keep their focus on what's required for go-live. And if it starts to slip, one has to be dynamic and be ready to search alternate, perhaps temporary, solutions.
Some tasks may simply not be possible or not in the time available. Agile just sort of tells you that - you can see how things are going and if they're going right or not.
Then you have a choice - find something to cut out or accept a later date. This is a mode of thinking that I find non developers have difficulty accepting. They want it all and they want it now and their modus operandi is to keep pretending that it's possible and suggesting that if they shout and stamp a bit that it will somehow rescue the situation.
Sure but that's life, not an issue with Agile. In fact, because Agile values "working software" in principle you should have more "working software" at the deadline than if you had gone waterfall-ish and spent your time writing detailed docs upfront.
I've seen that too, though I have to say that none of those were as waterfally as the actual waterfall process we used to follow. Back then it was quite literally 0 lines of code until spec (100s of pages) is complete.
Which ironically makes Agile even worse at times by forcing developers to implement incomplete spec, parts of which are often rewritten over and over again everytime the PM talks to the client.
A lot of managers confuse "Agile" with fast and think that "agile" teams are going to deliver software faster. In reality, it's often slower than waterfall. If you have a single feature that's never going to change, and you absolutely positively need it by Date X, then you're probably better off with waterfall.
In most of the industry "Agile" is just "doing waterfall really quickly", and for some reason nobody understands you have to stand during your daily micromanagement meetings.
"Oh, feature no 32 is going to take months and we realised that users can just...."
"No"