I don’t ask devs to commit, and neither should you

I've seen the 'C' word floating around the Agile blogosphere again recently - yes, "Commit". And I'm not talking about Git. I'm talking about that stick that incompetent scrum-masters use to beat their team members into submission so they can look good in the eyes of their managers.

You see, "commitment" to delivery individual stories is at best unnecessary and at worst an unconscious or subtily coerced lie. It is also counter-productive, as we will see later.

In reality, you can't 'commit' to crossing the street without being hit by a car tomorrow, so how can you 'commit' to delivering a story in two weeks? If you force your developers to "commit", there are three possible outcomes:

• All will go well, nothing unexpected happens, they deliver according to plan. In this case, you didn't need to get them to "commit" in the first place; you just needed to get the team agreed and aligned in the same direction, and trust them to do their job.
• Things will not go well. Your developers may "fake it", cut corners, introduce bugs, sloppy code and technical debt, and which will slow down future development, both because they need to spend extra time fixing said bugs, and because the code will be harder to update.
• Things will go really badly, the stories won't get delivered, and morale and motivation suffer.

A moderate amount of pressure is fine and healthy, and inductive to good work. Too much pressure shuts down innovation, stifles creativity, and results in poor quality and uninspiring results. Problem is, I rarely see only a "moderate amount" of pressure applied when the "C" word is in the air: it is almost invariably the latter case. In some cases, I've seen teams work for months with one weekend in four (that's being allowed to not come to work one weekend in four, not working one weekend in four). After six months, what do you think this does to code quality? Yes, it plummets, innovation and creativity flatlines, bugs feed back into the following sprints and effective productivity (not the "number of stories done" productivity being reported to management) is reduced by about 70%.

This is not how you manage creative types. This is not how you manage knowledge workers.

"But Business need to know when things will be delivered!" I call bullshit. Business don't give a hoot about when individual stories are delivered. What Business care about (or at least, what they should care about) is getting business capabilities that are of value to them, either in revenue generation or in some other more indirect way. And this is a different story entirely. If you deliver in small incremental slices, showing working features to the business as often as possible to get their feedback, you might be suprised at the amount of thing you don't need to implement before the business can start getting a return on their investment. There are many techniques, for example those discussed in XScale, to reason and plan at a very high level based on relative effort and relative ROI, which absolutely do not need to go down to the story level.

If you ask your developers to commit to deliver, despite knowing that uncertainty will inevitably raise it's head at some point, I wonder how you deal with your financial advisor. Do you ask that she commit to a 20% return on investment for your stocks this year. If you don't get your 20%, do you expect that she dig into her holiday savings or mortgage her house to make up the difference? If not, why not?

A far more productive approach is one based on Trust. In fact, the only "commitment" you need is from your team is that they will do their best to discover the fastest path to delivering a business capability that provides the value (or, more precisely, the return) that the business expects. Or to learn that this is not possible, and to find an alternative way to deliver value. Which is what any professional and motivated knowledge worker will do naturally. So the role of management is not to coerce the team into "commitments", but to help them understand how the business intends to get value out of a particular capability, and to work with them to discover the most effective way to deliver the features that will do just this. You shouldn't need to force anyone - we are no longer in high school, folks.

Scrum replaced the word "commit" with the more accurate "forecast" in 2011 , though the word has been slow to get out to many scrum masters, it seems. More recent approaches such as the Spotify model, Less and XScale all move strongly in this direction. It's time to teams to move on.