This has partially to do with not over committing at the beginning, but if the team fails to judge correctly, it has to do what needs to be done to fulfil its promises.
Unfortunately, this clear obligation gets forgotten to often – as I pointed out in the original post.
You seem to second my point.
Proper, grown-up coding on a business application is incredibly wearying on the mind, and results have shown time and time again through research studies and professional management that past 8 hours coding in a day the average programmer's code quality starts to deteriorate. Past 10 hours it goes negative - at this point the code base is actually being damaged.
"doing what needs to be done to fulfil the promise" is actually alerting the team that you've made a poor estimate of the effort required for this feature and need to recalibrate. It is absolutely not sticking with your poor estimate and delivering shoddy code to the project.
Rather than saying it is broken, it needs to be said that the team needs to improve. Continuous Improvement, it's where it's at.
No. Scrum is explicitly open to renegotiation. This is where burn-down charts come in to play. This is where having the product-owner be part of the team comes into play. If a feature is costing a lot more hours than anticipated due to unforeseen problems, it is expected that the team gets the product owner involved early so that a decision can be made: do we drop other work to deliver this feature, or do we drop other features to deliver this?
The core premise of scrum and other agile methodologies is that given the uncertainties inherent in software development, it is impossible to fix both the featureset and the schedule. Scrum fixes the schedule and explicitly allows for flexibility in the featureset. Other methodologies (like spiral, for example) fix the featureset and allow for flexibility in the schedule. Waterfall attempts to fix both, and fails as a methodology.
I've found, though perhaps it is a British cultural thing, that there are plenty of things people sit on and don't mention out of politeness - they only come out after a particularly bad failure.
Working software yes. If you break the build the minute before the end of Sprint then yeah you better fix it. Sensible teams resolve this by not committing at the last minute, and by having the Sprint end at, say, midday Thursday, not 9AM on Monday.
> if the team fails to judge correctly, it has to do what needs to be done to fulfil its promises.
Nope. There are no promises, no "clear obligation". Half the point of the daily standups is that if a feature is not going to be deliverable in its original form within the sprint, you catch this early, and then you talk about it, you have contact with the product owner, and you decide something sensible.
Also next time you plan a sprint, you reduce the commitment.
Isn't the entire point of scrum to enforce a sustainable pace of development? One that doesn't require heroics like having programmers come in on nights and weekends to finish? The entire point of tracking time and making burndown charts is so that you can avoid taking on too much work. If your team doesn't have the ability to push back on the requirements and say, "Hey, this is too much, we need to push features X, Y, and Z into the next sprint," you're not really doing scrum. You're doing kabuki-scrum, which is usually just waterfall with all the meetings relabeled.