This post is a response to the excellent Dysfunctional Commitment post, by George Dinwiddie. For context I recommend you read that post first, including the comments.
The term commitment has had a lot of attention again recently, especially in the context of Scrum’s “sprint commitment”. There is disagreement about whether or not commitment is a good thing in the context of software development where the environment is usually very complex, and there are so many unknowns. Part of the disagreement is a semantic one. Commitment can mean both “a pledge or promise” and “engagement; involvement” (dictionary.com). Those who decry commitment tend to focus on the first meaning, those, like me, who believe commitment is a valuable principle for building healthy organizations focus on the second.
Staying with the common context I’d like to look at why I believe that sprint commitment is a good thing, in spite of—or even because of—the apparent dysfunction surrounding its application.
“…if you had to guess, what would you say is the #1 asked question on agile forums, blogs, etc. over the last decade or so? Here’s my guess: ‘Our team continues to not make their sprint commitments, what do we do?’”
Rather than seeing this question as an indication that commitment is unhealthy, I see it as an opportunity to explore. Scrum has an uncanny knack, whether by design or otherwise, of surfacing organizational dysfunction. Let’s use it. There are two kinds of response to Troy’s question, the first goes roughly like this: Commitments cause pain. Let’s stop making sprint commitments—let’s move to kanban. It’s a decent solution. There is much about a continuous pull approach that fosters healthy team behavior. There is also much that simply buries the real problem that a remark like “we fail at commitment” could bring to light.
The second response is to welcome the information, and start digging: Why does the team fail to meet their commitment? They commit too much. Why do they commit too much—what drives them to keep doing that? Soon you will reach a root cause, which is likely something like this: Management is asking for commitment to both time and scope. They are asking for a promise. And they become frustrated when it is not met. Why are they doing this? There are many reasons, competitive edge, marketing opportunities, and so on. But I think the true cause is fear. Fear and mistrust. If we don’t push our people they will slack off. The truth is, people are much more likely to slack off when they are pushed in this way. It may not be intentional, but they become despondent, knowing nothing they do will satisfy the promise they were coerced into making.
If we dig down into the question/complaint in this way, we may find a way for the team to be committed in the way George describes: “The commitment within a team is not a commitment of certainty, but of solidarity and intent.” It is meaningful commitment we should seek, rather than throwing the concept away, skirting the real issues and looking for easier, softer ways. Abandoning scrum-the-process may give a sense of relief, and even empowerment, but I don’t believe any approach of avoidance will ultimately lead to the kinds of improvements good people are capable of, when they truly confront their own dysfunctions, and work through them.
I recently tweeted that commitment is noble [ref]. I stand by that. Seek its nobility, rather than focusing on a single meaning (i.e. promise—or even coerced promise). This is a very narrow interpretation of a valuable, human-centric principle that has great power to build a trusting, collaborative environment.
If we commit dysfunctionally, estimate dysfunctionally, collaborate dysfunctionally, or do anything else dysfunctionally, let’s first explore the dysfunction. When we see it clearly we can confront it, and remove it, rather than removing all the good principles to which we attach this word—good principles which perhaps we have not yet learned to embrace effectively.