As a father of three teenage boys, one of my primary parental missions is teaching the importance of meeting one’s commitments. After all, building trust in any relationship is based on honesty, and on consistently meeting commitments, right? So why would I post an article attacking the importance of meeting commitments for an Agile sprint?
1) Because meeting sprint commitments actually undermines the scrum team’s ability to meet project commitments
2) Because meeting sprint commitments encourages responsible scrum teams to “self-insure” against risk, invariably slowing things down
Let’s look at each of these reasons more closely.
On Reason #1, one might argue that the ability for a scrum team to meet commitments for each sprint directly correlates to the team’s ability to meet commitments for the project as a whole. Sounds logical, right? Something about the Whole = The Sum of Its Parts? In practice, however, we see how counter-productive it can be.
For example, take an Agile project that has planned for a total of 10 sprints, the first 7 of which are expected to deliver all “must-have” features that the customer requires, with additional “nice-to-have” features (aka “desirements”) slated for the final 3 sprints. The scrum team commits to delivering a given number of features for each sprint, based on historical data showing average velocity (story points per sprint) for the team.
Let’s assume that the scrum team cruises easily to delivering on all committed features for each of the first 6 sprints, but that Sprints 7 and 8 are plagued with difficulties, and that customer feedback on Sprint 9 reveals that some of the desirements are actually hard requirements. In other words, despite good planning and reasonably good execution, we find ourselves headed into the final sprint with must-have requirements still to be met. What if Murphy’s Law strikes Sprint 10, and we can’t deliver on the final few requirements in time?
Now let’s review this same scenario, but with no sprint commitments. That is, the scrum team simply runs hard on all sprints, getting as much done as they can. Given that the first 6 sprints were trouble-free, what if the team had been able to go beyond what was committed to on a couple of them? Under most “commitment” scenarios, most people don’t go beyond what’s committed to…after all, they’ve met their commitments! Time to celebrate!
Under a “run hard” scenario with no commitments, however, scrum-team members feel much more free to go well beyond what they might otherwise have committed to, and exploit times when things go well. In the example above, this could have enabled the scrum team to get 7 sprints worth of work done in the first 6 sprints, leaving the last 4 sprints for desirement features, and to deal with any unexpected complications. The only commitment being made—and met—is at the project level, which may be the only commitment that really matters to the customer anyway.
Let’s now turn to the “self-insurance” concern raised in Reason #2 above. If a scrum team is always committing to an aggressive level of work product, then all it takes is one little thing to throw a wrench in things one time, and the team will fail to meet that commitment. Seeking to avoid developing a reputation as a team that fails to deliver on its commitments, the scrum team will act more responsibly going forward, and “self-insure” against the risk of things going awry by only committing to a level of work product that they are confident they can deliver. So they sign up for less. And as described in Reason #1, most of us are unlikely to go beyond the commitment, once we deliver on it. So the team goes slower, and delivers less.
A much better alternative is to aggregate the sprint-level risk at the project level, and just let the scrum team do its thing, breaking speed records on good sprints, and slogging through bad sprints as best they can. As long as the project’s “desirement sprints” are adequate to absorb the aggregated risks faced on all bad sprints, the project will deliver on its commitment—especially if the good sprints are exploited fully.
Lots of Agile practitioners have tried this, with consistently superior results—and by the way, the principles apply even more strongly to traditional task execution by individuals (vs. scrum teams), so all projects can benefit from this, not just Agile ones.
Give it a go, and let me know how it works for your teams.