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.
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.
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. 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
- Someone else
What Is to Be Done?
- The managers should move the deadline 2x (or 3x) times later than the original team's estimate.
- Team members should be encouraged to do all the work they committed to no matter what (by issuing penalties for failed sprints)
- The team should drop Scrum because it doesn't fit the company deadline policy
- We should all drop software development and join a monastery
- ???
Best Answer
I see several fundamental management issues in your example:
if a Scrum-Addicts manager signs a "hard-deadline" contract, but adds only a safety margin of 33% in a situation where "a new system is involved", that is pretty reckless.
the availability of delivering at least x% of the features after one month could have been used to negotiate a contract where the customers pays the money at least partially when he gets only 80% of the features at the deadline. An all-or-nothing contract is something neither the software vendor nor the customer will benefit from - this means not just 0 money for the vendor, but also 0 features for the customer. And an all-or-nothing development methodology like "Waterfall" will only let you write such contracts, an agile approach offers additional possibilities.
looking at the results of the first one or two sprints should have made obvious to the manager that the team cannot meet the deadline. So he should have taken earlier actions, and re-prioritize the remaining tasks and features, or try to re-negotiate with the customer earlier. For example, the manager could have tried to downsize the scope of some of the remaining features, so the team could have delivered all features mentioned in the contract, but each of them in a reduced scope.
If a task turns out to take longer than you thought, no development methodology will save you from that. But an agile approach like Scrum gives management more opportunities to control what happens in that situation. If they don't make use of those opportunities, it is clearly their fault, not the team's, not the fault of "Scrum", and not the customer's fault because "he does not accept agility".