I have a commitment problem.

Ok, well, I should say that I’ve had a problem with the word “commitment” in software development for a long time.

Here are the definitions that Google gives me: 1) “the state or quality of being dedicated to a cause, activity, etc.” and 2) “an engagement or obligation that restricts freedom of action.”

The first definition doesn’t bother me much. “Being dedicated to a cause” makes a lot of sense to me and seems to fit with the spirit of delivering value to our customers.

The problem is that most folks I run into in the software development world have the second definition in mind when they use the word commitment.

It’s been incredibly common for my teams to be asked to “commit” to getting some feature accomplished in a given time frame. That’s not a direct request for the the team to “restrict their freedom of action”, but it’s pretty darn close. By setting boundaries on scope and time, the team is left with little freedom in how to achieve the underlying goal (which is often very different than the feature they’re asked to build).

After almost 20 years building software I don’t think I’ve ever seen this approach succeed. Software is design work. It’s emergent. It’s unpredictable. We can be dedicated to the cause of solving a problem or achieving some goal. I don’t know that we can be dedicated to knocking out a list of features in a quarter, though.

Theory X vs Theory Y Managers and the Cycles of Mistrust

I was listening to an Agile for Humans episode a while back that introduced me to Theory X vs Theory Y management. In short, Theory X managers believe people don’t like work and would just coast through the day if given the opportunity. Theory Y managers believe that people are intrinsically motivated and want to do a good job.

I’ve worked with both kinds of of managers. Theory X managers ask for commitments because they do not trust their teams, frankly. There is a belief that no progress on a project will be made without a commitment. It’s unhealthy and sad, but common in our industry.

It can lead to a cycle of mistrust, and the team will start behaving in the way that the manager expects them to. An unrealistic project commitment is requested (or often demanded), the team tries their best and ultimately comes up short (or cuts corners and delivers a half-baked product), and an even more aggressive commitment is set for the next project to create a “sense of urgency” and “deliver on our commitments”.

Nobody wins. Not the development team. Not the managers. And especially not the customers.

I don’t think that I’ve ever worked with another developer who needed fixed scope and date commitments to bring their best to work every day. I have seen plenty of resentment and, in some cases, burnout when this is the the organizational culture, though.

I have seen people do their best when they’re committed to a cause. Give people a clear goal and the authority to make decisions and I guarantee you’ll get a better outcome than a “commit and drive” approach.

It’s leadership’s responsibility to create the space for teams to work this way.

Theory X managers usually think that their duties include managing to a schedule and keeping the team on track (aka driving the project). They see
people not working hard enough or long enough and label them as not being “committed”. They want people who will “do whatever it takes” to ship a feature, but what they mean is people who will put in extra time.

Theory Y managers see their job as clearing the path for teams to unlock their maximum awesomeness. They see the broken system that teams are working in and help them fix it. Asking people to “do whatever it takes” means re-imagining the problem space or solution to achieve the goal. It doesn’t mean burning people out in order to stick to a make believe plan.

Part of me understands the Theory X mentality. It’s natural to restrict the freedom of a team when you believe that everyone is in it for themselves. It’s much easier to blame a team for not hitting commitments than it is to fight the traditional organizational currents of fixed scope and timelines.

Forcing teams to commit to dates or scope is imposing restrictions on them. It’s an easy way to dis-empower an otherwise creative group of people. It’s also the wrong solution for the organization because it sets unrealistic expectations while almost always delivering the wrong thing.

Asking teams to commit to a goal then giving them to freedom to achieve it is empowering. It’s a sign that the team is trusted to do the right thing. Teams I’ve worked on thrive in this environment and deliver amazing solutions.

That’s the kind of commitment I can commit to.

Update 3/13/19: One of my friends (thanks, Matt!) pointed out that the Scrum Guide dropped the word commitment in favor of forecast back in 2011. It’s interesting that Scrum updated their language to avoid the type of abuse that can come from a team not “meeting their commitments” 8 years ago, yet this mentality is still prevalent in so-called Scrum organizations.

[ad name=”Footer”]