The Mystery of Commitment

I have this problem with commitment, and it’s not because I’m a guy.

You may or may not know that Scrum comes complete with a set of values by which we are supposed to guide our daily professional lives, or at least our life within the team. Of the five values, Commitment might just be the most famous. It’s supposed to be really important. It’s supposed to be a Bad Thing if a team can’t commit to delivering a certain amount of value each sprint and then deliver it.

So here I am, going “Well, uh…if the team just gets on with it and develops stories in value order then who cares about commitment?  They’re gonna go whatever speed they go and committing ain’t gonna change that.” Fair question, right?

I look at the Agile estimation process and I like it, especially when it’s done correctly. Then I think, “No way does this lead to any kind of exact or accurate estimate. In fact, it’s not supposed to!” How could anybody possibly think that this is exact enough to hold a team to a standard of completion or a commitment to deliver? And what a standard! Some coaches will tell you that teams should be able to complete 90%+ of what they commit to. Others will say the team should hit its commitment 100% on four out of every five sprints. Those are some really high expectations.

My problem is that I just don’t get it. I can’t make it logical. First of all, it can’t be a do-or-die commitment because that’s not sustainable and hence, not Agile. It can only be a “we promise to try really hard” commitment, which has always seemed a little wishy-washy to me. So if I’m not committing to getting a bunch of stories completed do-or-die, then what is my team committing to, really?

And back to my original question, what happens if you don’t commit but you still do work anyway?

I keep thinking, “If the team builds the most software possible in the timebox, then what does commitment have to do with it?” “If we measure the team’s ability to produce valuable software using velocity, then doesn’t that make things predictable and thereby solve our need to support business decision-making?” Does the team do more or better work when it commits?” “What does commitment mean if it doesn’t mean ‘at all costs, even if we have to work around the clock’”?

So, after a couple of years agonizing, unable to confide my doctrinal sins to my wife or my boss or colleagues, I think Ifinally got it. Michele Sliger gave me the lightbulb,  but I don’t remember exactly what she said. But I know it was her, because when I woke up that morning I still didn’t get it and then I drank beer with her and when I went to sleep that night I had my new version of it. So I will paraphrase what I don’t remember that she said.

The thing a team commits to when they commit at the end of the sprint is not the list of user stories per se. What they commit to, at least in terms of what makes sense to me, is a unified, focused (another scrum value), relentless, best-effort sprint oriented around those user stories.

In other words, and this seemed strange to me when I first thought it but I can’t analyze it away, THE SPRINT COMMITMENT IS THE WAY A SELF-ORGANIZING SCRUM TEAM PROVIDES ITSELF WITH DIRECTION AND INSPIRATION.

That is too weird for words, isn’t it? The sprint commitment is a surrogate for a manager? I guess so.

Now I understand when people admonish against labeling a sprint that completes all of its committed user stories as a “success” and labeling a sprint that misses a story as a “failure”. A failed sprint is one in which the team does not maintain a relentless, focused, unified, professional effort based on the committed Product Backlog items.  A success is one in which the team does that, regardless of the number of stories that are completed. Sure, we worry when they don’t display predictability and we retrospect and fix it, but the team doesn’t fail if they are working well and the technology bites back or random Acts of God get in their way. They fail if they don’t work well. They fail if they don’t pay attention. They fail if they don’t build quality software, or if they don’t bother meeting the Definition of Done. They fail if they don’t build the most valuable software that could have been built in the sprint. Otherwise, they succeed.

And Commitment gets them there.

Advertisements

3 thoughts on “The Mystery of Commitment

  1. Personally, I think this commitment thing is banal hokum.

    Another blogger had mentioned that it’s impossible to “accurately commit”, because estimates are vague. Either someone will over or under commit. The odds of nailing it are small.

    Meanwhile, as a husband, I don’t think most couples commit to each other every day, renewing their vows. This is a much more important relationship than business.

    Should they? Maybe. In a business sense should people commit to each other every day? It seems pedantic.

    Does business commit to the team? Did they get the budget right? Did they get the market right? Will they offshore the project?

    Commitment needs to mean more than the team commiting to each other. It is meaningless otherwise

    Jordan

  2. Hi Jordan,

    Is that a greenwing macaw you have there? I have a B&G and an eclectus. But I digress. 🙂

    I think we’re mostly in agreement. I was trying to say that the idea of committing to deliver a specific list of deliverables for a sprint is not about delivering the exact number of deliverables. I think you agreed with that notion.

    However, if you imagine a world without external supervision (management) at all, then you can see that there needs to be some mechanism that causes the entire team to voluntarily work together on something specific. That mechanism seems to be the scrum commitment. It is between the members of the team and its purpose is to get everybody on the team to work on the same things together.

    I agree with your comments about bidirectional commitment with the organization or company, but I’m treating that ‘commitment’ as a separate issue.

    So, to rephrase, I can ‘accurately commit’ to a list of things I will focus on and try to produce, and I can use that commitment within the team to reassure myself that everybody will work together on a shared set of goals. The commitment isn’t what produces the surprising (and not uncommon) outcome of delivering what was committed. That is primarily the function of the estimation and velocity feedback cycle.

    Thanks for the comment!

    alan

  3. Hi… I don’t know what kind of bird it is… It’s just something that I shot at the zoo one day…… You probably know a lot more about it than I do!

    Cheers,
    Jordan

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s