One of the things that usually happen when they push and push and push for some feature to get rolled out in the next quarter is that it often turns out to be a gigantic flop. Engineers are forced to spend hours they can't get back at the whim of management for something that was a complete and utter failure. I could imagine few things more demoralizing than this.
Agile is really meant to be about self organizing teams that take ownership of their own work and deliveries. The scrum master and product owner are just there to facilitate that.
When a team hits a blocker on a tight schedule -- particularly across third party teams, it's up to the management to figure out a solution -- even if it means gasp delaying the release by one sprint.
What software development methodology does not work well under these circumstances?
I believe some people within certain organizations are aware of the waste at some point or another, but it's the price said certain organizations chooses to pay in order to implement a great micromanagement system.
Run into a blocker? Too bad, should have seen it coming during our scrum meetings and follow-up refinements.
We engineers had two business analysts, a scrum master, and two managers that resided "above" us in rank all working to keep the "flow" of the sprints alive to help ensure we meet our deadlines.
It was the most stressful tech job/environment I've ever been part of and everything was micro-managed by said 5 people to the point that they were blockers to our progress - scheduling multiple meetings everyday that would easily consume 3-4 hours.
Our backlog would grow everyday as everyone scrambled to finish tasks and our architecture was a patch-work of systems that only one person truly understood because he had been with the company since it's inception.
I was hired as a senior engineer along with three other mid-level engineers - all three quit within four months. I left after six.
Sprints/agile/scrums are generally a good thing IF and ONLY IF you have a capable manager/scrum master leading and organizing the team who truly understands time management and finnicky nature of software development. Otherwise, it quickly falls off the rails and leads to churn and burn.