Many Scrum books and articles say that a failed sprint (when the team fails to complete some features from the Sprint Backlog) is not something that bad, it happens from time to time, and it can actually be useful if the team learns from their mistakes and improves something in the following sprints. And the team should not be punished for not completing the work they committed to.
The way you "punish" this kind of behavior is by limiting the amount of work the ones who didn't finish can take on next sprint. Chances to work on cool stuff are vanishing. The reward for doing good work is more work.
This looks great from the developer's point of view,
however, let's say we have a software company "Scrum-Addicts LLC" developing something for serious clients ("Money-Bags Corporation"):
Scrum-Addicts managers suggest making a piece of software for Money-Bags
They agree on a list of features, and Money-Bags asks to provide a shipping date
Scrum-Addicts managers consult their scrum team, and the team says it will take 3 week-long sprints to complete all of the features
Scrum-Addicts manager adds 1 week to be safe, promises to ship the software in 1 month and signs a contract with Money-Bags
After 4 sprints (shipping deadline) Scrum team can only deliver 80% of features (because of inexperience with the new system, the need to fix critical bugs in previous features in production environment, etc...)
As Scrum suggests, at this point, the product is potentially shippable, but Money-Bags needs 100% of features, as mentioned in the contract. So they break the contract and pay nothing.
Scrum-Addicts is on the brink of bankruptcy because they got no money from Money-Bags, and the investors were disappointed with the results and are unwilling to help the company any more.
If on Monday I bet you $100 that it will rain on Thursday and it doesn't rain until Friday you'd be right to take my money. If, rather than a chance to gamble, what you want is a weather forecast then we need a contract that lets me give you an updated forecast on Tuesday.
Obviously, no software company wants to be in Scrum-Addicts' shoes. What I fail to understand about Agile and Scrum is how they suggest teams should deal with planning and deadlines to avoid the situation described above.
Think about WHY MB wants to take their ball and go home. MB didn't demand the work be done in a month at the outset. SA promised 100% of critical features in one month and didn't deliver. SA set the deadline not MB. SA even arbitrarily added a week to the deadline. So why is this a deadline?
Occasionally when competing for work software companies give in to the temptation to show off and promise the moon. Professionals carefully establish whether a moon is even required. Which is the more critical need for MoneyBags? 100% of features or a functioning product in a month's time? Do they even know what is truly critical? Is there some upcoming event setting a hard deadline?
If I was Scrum-Addicts negotiating this contract I'd want to know a lot more about Money-Bags business needs and structure the contract to grant as much flexibility as Money-Bags is comfortable with. I'd teach them how the agile process works so they know what to expect from us.
This way rather than expecting everything to be suddenly working perfectly in a month they'd be expecting to be evaluating the first deliverable in 1 to 2 weeks.
So, to summarize, I have 2 questions:
Who is to Blame?
Managers, because it's their job to do the proper planning
The team, because they committed to doing more work than they could
Anyone could have stopped this travesty before we got a month down the road.
I could go as far as blaming Money-Bags Corp for hiring a team that obviously fraudulently represented a waterfall process as being agile. The contract itself makes it clear this is not agile. Planning to be done in a month doesn't make it agile.
If you insist that it's agile, it's agile with only one sprint that is a month long. Which, yeah, I wouldn't recommend because that's, again, the same thing as waterfall.
What Is to Be Done?
How about agile? Deliver something every sprint? Get feedback before the deadline? Week long sprints? How about renegotiating the draconian contract the very moment you suspect the deadline is in danger rather than hiding and praying? At the very least you can stop wasting time on a doomed project and find a more reasonable customer.
The managers should move the deadline 2x (or 3x) times later than the original team's estimate.
Deadline multipliers are about as useful as setting your watch 15 minutes early so you'll never be late. You can only fool yourself so long before you realize what you're up to.
Early estimates are wrong. Try to capture how wrong. 5 weeks, give or take a few weeks is a simple expression that lets you express how uncertain the completion date really is. Rather than trying to guess accurately, you guess how wild your guess is. Do some real work and get some real data. Then you can start making estimates with a narrower range. One to two weeks is plenty of time to do this.
Team members should be encouraged to do all the work they committed to no matter what (by issuing penalties for failed sprints)
Team members should be encouraged. Failed, committed, or otherwise. Rather than constructing any artificial consequence such as punishments or even bonuses (carrot and stick) studies have shown that people doing creative work such as programming respond best if provided three things: Autonomy, Mastery, and Purpose.
Daniel Pink has a TED talk about this. The talk is about motivation not agile but I easily saw how to map these points to agile:
Autonomy - I want to direct my own life - Let me pick work from the backlog.
Mastery - I want to get better at something that matters - Customer feedback.
Purpose - I want to be part of something larger than myself - A collaborative team.
The team should drop Scrum because it doesn't fit the company deadline policy
Scrum can hit a deadline more accurately than waterfall. Given a deadline scrum can meet it. It might meet it with only 1 of 47 features depending on time, feature, and skill but it can meet it.
An agile project can be styled so extremely that every night when the team goes home it's ready to ship. This seems silly unless you think of shipping as asking the customer to test and provide feedback. The sooner that happens the sooner you can make adjustments. This hits every possible deadline. Just not every feature. But it steers you to the features that matter.
We should all drop software development and join a monastery
Right, like locking me up in a room away from real life is gonna make me write LESS code.
I've edited this answer down to size. If you're curious read the edit history.