With software, typically you have the following metrics:
- Time scale. You have the iteration.
- Scope. You have fixed the scope.
- Resources. You have the team members.
- Quality. Quality has to be 100%
When the pressure is on, which one do you sacrifice? Do you expect the team to create more time scale by working overtime? Do you drop stories? Additional developers probably won't get up to speed quickly enough? or do you just test the basics, and cross your fingers?
What I have seen happen in all the scrum teams I've worked with is that they are under pressure to continually increase 'scope' as its a measure of how good the team is, that to deliver on this, teams over work their hours, and that quality gets squeezed, as developers deliver late, and the end deadline cannot be moved.
What Scrum was intended to deliver was:
Time scale: we review the progress of the product at fixed, periodic occasions which ensure we are delivering features that the customer need.
Resources: We have clarity over who is working in the team for the iteration. developers are not pulled around doing painful context switches.
Quality: We value quality above all. We make sure that everything we produce is properly tested and if we have not tested it 100% then its not yet done.
Scope: We are giving the business visibility over what we expect to deliver at the end of this iteration - based on our past experiences.
In this environment, when the pressure is on, its Scope that's sacrificed.
How to make scrum work?
That is the wrong question. The right question is what kind of output does the company need from the development team? Do they need a quality product? or do they need to release software to a deadline?
When they have come to terms with this, then they will be able to organise the appropriate environment for their developers. Scrum, kanban, XP can all do this, but they are all environment dependent.