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

Serge Beaumont

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! :-)

Comments (6)

  1. Geert Bossuyt - Reply

    March 24, 2010 at 5:58 pm

    Hi Serge,

    Interesting stuff.
    What I like to 'preach' is that you should never commit to something you don't believe in. I really like the Fist of Five and your ideas on Failure.

    You write "t the team pledges to each other that they will strive to reach the goal".
    To make this clear to the Team ( and its environment) and thus make it happen, the definition of Commitment I like to use is :
    'To Commit' is the ability to make choices that lead to deliver the promised goal.'
    [From Bossuyt's Agile Philosophy Manual :-)]

    This means, Commitment is not about delivering the entire Sprint goal no matter what happens. 'To commit' is about daring to make choices, as a Team or with your product owner, that will still lead to delivering the promised Goal.
    Sometimes this means you will not entirely deliver a story as you intended to deliver it at the start of the Sprint, and therefor might not burn it, but you will al least deliver something and learn from it. Sometimes you will find other ways to deliver the Sprint Goal. The more a Team is able to make choices, the more the promised goal will be delivered.

  2. Machiel Groeneveld - Reply

    March 24, 2010 at 10:06 pm

    Excellent post! I'm not sure where the 'commitment = accountable' idea comes from. I've looked it up in the 'Black Scrum Book' and it doesn't state anything of the sort. In Scrum 1.0 the team is never wrong or punished, it's achievements are just there for inspection, not judgement.

    One nice quote in the book from Takeuchi and Nokana: "...the process tends to produce significant quantities of mistakes. However, these are viewed invariably from the plus side as being valuable learning experiences. In the end, the bottom line is that chaotic process tends to produce more revolutionary products faster than the old sequential development process'.

    Perhaps it's the sequential and linear view that sees failing Sprint commitment (and it's predictability) as something to get rid of.

  3. Vincent Partington - Reply

    March 25, 2010 at 10:38 am

    Last year Wired magazine had a whole issue devoted to the goodness of failure. Some interesting stories in there, although the one about Duke Nukem was more sad than really helpful. But all in all, I tend to agree with the idea that failure can be a good thing.

    Where I think you are going overboard is when you say that "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.". As I understand it, you are saying that there is always something to improve so you should introduce controlled failure to look for those improvement points. But doing this all the time will not only stress the system but can also demoralize the team. Also, I would like to see some backup on your assertion that the main goal of Scrum is to surface problems, etc.

    Finally, to nitpick, I don't understand your definition of normal when you say "We're mostly in a state of hyper-improductivity, and what Jeff calls "the hyper-productive state" is what I consider the normal state". What are saying here? Are we mostly abnormal? ;-)

  4. Serge Beaumont - Reply

    March 25, 2010 at 3:01 pm

    @Vincent:

    - re "...but can also demoralize the team".

    With controlled failure I don't mean that you fail overall: I mean that the team will have succeeded overall, and have found some pain points to improve.

    Another point is that demoralizing due to failure also has a lot to do with how you view failure. I guess I have a more neutral interpretation of the word. Failure simply means "not according to expectations", like the distinction between failures and errors in programming.

    Finally, you're probably aware of Csíkszentmihályi's "flow". You are in flow when there is the right balance between your capabilities and your challenges. That is the balance you're looking for here: the right amount of challenge.

    - re The assertion that the main goal of Scrum is to surface problems:

    I got this from Ken Schwaber in an interview somewhere, but the Scrum Guide (see http://scrum.org) also states it:

    "The role of Scrum is to surface the relative efficacy of your development practices so that you can improve upon them while providing a framework within which complex products can be developed."

    It's written down as "surfacing the relative efficacy", but you get the drift. Find problems, shoot them.

    - re "Are we mostly abnormal?"

    Sadly, but yes. I wouldn't call it "abnormal" though, just "improductive". Nice troll, though :-).

  5. Lars Vonk - Reply

    March 27, 2010 at 5:08 pm

    Hi Serge, are you really saying that the team is not accountable whatsoever on the promises they make and the products they deliver?

  6. Serge Beaumont - Reply

    March 31, 2010 at 9:13 am

    @Lars: no, that is not what I mean to say. Don't take what I say here to the other extreme, I think you're reading too much into it :-).

    I focus on a specific problem, that a wrong interpretation of committing leads to an accountability to results that hampers the inspect-and-adapt cycle. Of course a team is accountable to whatever their responsibilities are. But IMHO it is not useful to hold a team accountable to the results (for the reasons stated above).

    If I hold a team accountable to anything, it is that they *learn* (and its close cousin, that they improve). I don't care so much about their specific performance at the moment as much as I care about them doing it a bit better with each iteration. Out of that simple responsibility I have seen everything else follow, including the team's performance with results.

Add a Comment