Archive for April, 2011

The Mystery of Commitment

April 27, 2011

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.


Get every new post delivered to your Inbox.