"Committing" to a Sprint and failing is a GOOD thing!

What does it mean when a Scrum team "commits to a Sprint"? There is a subtlety in the English language that leads to misinterpretation and misuse of the verb "to commit". I have seen too many cases where a team is held accountable ("bad team, bad!") because they did not achieve their Sprint goal in some way. And it will be accompanied by the accusation: "...but you committed to the Sprint, didn't you?". As a coach, this is the moment I step in to explain what "to commit" really means, and that you want to fail every now and then: succeeding every time is a failure mode all of its own.

The meaning of "to commit"

The Apple Thesaurus gives five meanings to the verb "to commit":

commit verb

1. he committed a murder: CARRY OUT, do, perpetrate, engage in, enact, execute, effect, accomplish; be responsible for; (informal) pull off.
2. she was committed to their care: ENTRUST, consign, assign, deliver, give, hand over, relinquish; formal commend.
3. they committed themselves to the project: PLEDGE, devote, apply, give, dedicate.
4. the judge committed him to prison: CONSIGN, send, deliver, confine.
5. her husband had her committed: HOSPITALIZE, confine, institutionalize, put away; certify.

See all the different nuances in that one word? The different interpretations are what trip us up. Certainly, one of the meanings is "to pledge", which is the one that is referred to when a team is held accountable, but what about "committing" a transaction in a database? Did the database just solemnly pledge to keep your data? No, that meaning is similar to the expression "committing something to memory", closer to the "carry out" or "entrust" meaning of the word. Another meaning of "to commit", or specifically "committed" (thanks to Erik Gibson for helping clarify this one) is when you're at a point of no return. For instance, when you're running and you want to jump over a chair there is a point before which you can still slow down and stop before the chair, and after which your momentum forces you to carry on with the jump or else crash into that chair. At that point you are committed.

Commit what to whom?

In our context, the first true meaning of "to commit" is about fixing the scope of a Sprint. During Sprint Planning I the Scrum Team and the Product Owner select (or more formally: negotiate) the scope of the next Sprint. Since that scope should not change during the Sprint you're at a point of no return here. The moment of commitment fixes the scope for that Sprint, just like in a database transaction. Note that this is a commitment that applies to everyone: nobody should change the scope from that point onwards, whether they are Team members, Product Owners, managers, or stakeholders. Everybody is committed. The second true meaning of "to commit" is that the team pledges to each other that they will strive to reach the goal. Self-organization is one of the cornerstones of an Agile team, and self-organization builds on intrinsic motivation (or self-motivation). When team members commit, they are saying that they are intrinsically motivated to self-organize and contribute to the team. They commit primarily to the team process, not the result.

Commitment, confidence and the Fist of Five

Team members may not commit (in the "team pledge" sense) because there is something wrong with the team dynamics, or because that team member has some personal issue. Although important to look out for, I'll not discuss it here: that is something for a soft-skills post. The other main reason - which I will discuss - deals with confidence. An unattainable goal kills intrinsic motivation, so it is important to know if a team thinks they have a reasonable chance to reach the Sprint goal. Ambitious is fine, unobtainable is not. So how do you find out if a team has the necessary confidence to commit (in the "team pledge" sense)? A nice and easy tool is the Fist of Five. Before the chosen scope is fixed, the team is asked to "do a Fist of Five" if they think the Sprint goal can be achieved. Every team member then holds up a number of fingers corresponding to their confidence level:

• 1 finger: Not a snowball's chance in hell!
• 2 fingers: I don't think it's possible...
• 3 fingers: There's a 50/50 chance that we'll make it.
• 4 fingers: We have a reasonable chance of making it (80%).
• 5 fingers: It's a sure thing!

When you see only 1's and 2's, you can be pretty sure that the team will emotionally detach: they don't believe it can be done. When you see mostly 4's, you're in a very good position. But... should you be going for mostly 5's, all the time? Doesn't that mean top-confidence, and a super-super team? Maybe, but it's not the best place to be: which leads into my final point, the value of potential failure.

Failure is good

If you've been around me for any stretch of time, you are almost certain to have heard a mantra I constantly repeat: Agile does not solve your problems, it just makes them painfully clear. The Scrum framework's most important - nay, main - goal is to surface problems, impediments, waste and other forms of organizational insanity, so that you have targets for improvement. Jeff Sutherland talks about "hyper-productivity" a lot, but this is one term on which I don't agree with him. I'm in the Lean camp on this one. We're mostly in a state of hyper-improductivity, and what Jeff calls "the hyper-productive state" is what I consider the normal state, after removing all the waste that blocks our natural capability for greatness (cue dramatic tear and handkerchief). From my viewpoint you want to put just enough pressure on the system to induce controlled failure. Controlled failure means that you don't fail a Sprint outright, but for instance that you fail to achieve "Done" on one user story of the five the team committed to at the beginning of the Sprint. Those failures lead to improvements of all kinds: in the product, the process, the team, the organization... And that is why I think all 5's, and never failing a Sprint is a bad thing. If you can't fail, you can't learn, it's that simple.

Conclusion

The word "commitment" is a word that is used incorrectly in many cases. It is not about accountability and holding a team in judgement after a Sprint. Commitment is about fixing scope, and a pledge team members make to each other to support self-organization. Finally, the use of commitment should not lead to "a sure thing", because otherwise you'll never achieve the greatest gift Scrum can give you: the chance to learn. May all your days be filled with failure! :-)