Earlier quoted context omitted.
I think you are missing a couple, somewhat related failure modes. First, if the software project is part of a larger integrated hardware/software project, people above the project manager may be making promises of deliverables without consulting the program manager at all, thus creating externally-imposed deadlines that cannot be changed without rippling through to other teams, who may or may not be in your own compa…
Disclaimer: I've only recently decided to Stop Worrying and Love the Scrum, so my perspective on the subject may still be heretical. That said: I think these are not failure modes that can be laid at Agile's feet. They represent a situation that Agile quite explicitly does not even attempt to fix. A key part of the (for lack of a better word) Zen of Agile is that on anything above the smallest of scales, it's impossi…
I'll add that Agile teams should also have something releasable every iteration (which ideally is every week). When that's true, dates are less of a problem. Instead of managers sweating engineers over when it will be done, managers in an Agile context spend their time arguing with other managers about the business question of whether to release something small and soon or something bigger and later.
In a well-run Agile context, anyhow. If you're not seeing those behaviors, but instead see the traditional drama, a high-pressure single convergence on a fixed date with fixed feature goals, then it's the sort of faux Agile this article is talking about.