A Town Called Commitment

In honor of Doctor Who being back on, I thought we should talk about a town called commitment.  This is a town where everyone goes around making commitments to one another.  One day, Madame Mayor called for a town meeting.  At the beginning to the meeting, she said, “I commit that we will get through all the agenda items we have today…”.  Just as she finished speaking a blue telephone box with the words Police Box began to materialize in the middle room…..

Tardis Tour Wales 2013 (2)

Recently, I suggested that estimates are not commitments and advised that when teams are asked for estimates, they should make an effort to understand if they are truly being asked for a commitment. Simple, right?  Well, not so fast my friends.  Commitments are an interesting thing with implications and ramifications on both individual and team behavior.

I once heard the story of a man who made the commitment to his dying wife that he would never remarry because he loved her so much.  Years later, he met someone he feel madly in love with.  What do you think happened to his commitment?  If you make a commitment to attend a friends wedding, you are pledging to be at that friends wedding.  You have made a promise (yes a promise) that you will do whatever you can do to be at your friends wedding.  That’s a commitment.  When we make commitments, we are implying that we have a lot of control over the final outcome.  Some of you reading this are probably thinking that I’m taking this commitment thing a bit too far. Um, I don’t think so.  My experience in life would suggest to me that when people say they are making a commitment to something, those who hear the commitment are largely interpreting it as a promise for the individual to do what they have said. This is why there is disappointment and frustration when commitments are not met.

Others may read this and say that anyone who sees a commitment as a promise (or something similar) is making a mistake and shouldn’t. But why shouldn’t they? Isn’t that at the end of the day what a commitment really is?  Why would we attempt to redefine commitment in certain contexts?

Commitments inherently runs the risk of not being met.  That is just a fact of life.  Inclement weather can hit your town grounding all the flights and making it impossible to get to your best friends wedding.  You can meet someone you fall madly in love with and remarry.  What you thought would be a few lines of code changes turns out to be something much more involved.  Things happen.  Things happen every day. It’s important to realize that the more people that are involved in making a shared commitment, the larger the risk of it not being met. (This is another reason for small(er) teams in software development but I digress).  After playing team sports for most of my life at a pretty competitive level, I learned that lesson the hard way.  This is why you’ll rarely see a coach commit to wining a game (outcome) and most players would hedge on doing so.  I mean we all saw how it ended for LeBron and Heat after promising “…not one, not two, not three…”.

Commitments also come in conflict with one another.  Making a commitment to one thing very often impacts commitments to something else. Daily, I have to excuse myself from one meeting I committed to in order to attend another.  Its not uncommon to ask a team to be committed to quality but then also ask them to commit to delivering X number of stories in an iteration – which commitment do you expect them to honor when there is conflict (and there will be a conflict)? The quality commitment or the number of stories commitment?

Commitments made too early can also lock us into a solution prematurely and prevent us from exercising other options that we may have had.  We see this when teams make a wholesale investment in a particular solution to a problem making impossible to leverage any of the other options on the table. (Yes enterprise/solution architects, I am talking to us).

This is the very reason why we should be careful what we make commitments on and when we make those commitments.  In knowledge work (and software development in particular), I suggest considering the following when thinking/talking about commitments:

  • Do not make goals, commitments
  • Have (and understand your) options
  • When (and if) you have to make commitments, make them at the last responsible moment
  • Choose commitments to behaviors and causes over commitments to particular outcomes
  • Consult people before committing them to a cause or outcome
  • Don’t make a commitment  you don’t think you can keep
  • When you make commitments, do your best to honor them

I had started this blog post before I read http://commitment-thebook.com/ but I would encourage anyone who hasn’t read the book to do so.  Some insightful nuggets are contained within it.

Commitments are valuable and precious, use them wisely.  Now that sounds like something the good Doctor would say.



Photo of Tardis: By Rept0n1x (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)%5D, via Wikimedia Commons”



Estimates Are Not Commitments But…

Unfortunately, they very often are.  Recently, during an interview, I asked the candidate what they thought about the notion that “estimates are not commitments“.  The candidates answer was:

Once an estimate is put down on paper, it unfortunately becomes a commitment.

Performing a search for estimates are not commitments returns a good number of results so this is not really a new subject.  Yet, to be fair, it’s important to realize that many of the articles are authored by individuals in the Agile software development delivery space so do we have an agenda?

In previous articles, I’ve tried to define what an estimate is, so I won’t repeat that here but suffice it to say, that an estimate is an approximation of a measure.  On the other hand, a commitment is defined as the following:

  • an act of committing to a charge or trust
  • an agreement or pledge to do something in the future

So its very clear that estimate and commitment are not one and the same thing.  How is it then, that estimates are very often interpreted and/or immediately translated to commitments?  I’m not sure I have a good answer for that yet, but I’d love to your feedback!

What I do think is important is understanding what the the requestor of an estimate is looking for.  An estimate?  A commitment?   The response for each could be remarkably different.  So when you are being asked for an estimate (and let’s just assume for a second that one is truly needed), make sure you understand what you are really  being asked for.

Estimates are not commitments.

Resources Never Die

This quick post  is a result of the following Twitter conversation:

In the sphere of business and project management, people are considered to be resources like raw materials, chairs, pens, money etc etc.  Those things can’t get things done on their own.  They require people.  The Merriam-Webster dictionary definition for resource is:

: something that a country has and can use to increase its wealth

: a supply of something (such as money) that someone has and can use when it is needed

: a place or thing that provides something useful

Does any of those definitions describe you or the people you work with?  Are you a resource?  Are they a resource?  Do you run out of supply?  Do they run out of supply?  Are you a thing? Or better yet, something?  Are you fungible? Do you think others are fungible?

See people for the people that they are.  People that take resources and do something meaningful with them.  Stop referring to your people as resources. When you are discussing people, discuss them as people and not as resources.  Yes, I know its learned behavior but I’m optimistic that you can unlearn that  behavior and learn something new.

Resources never die.

Excess Luggage


Excess luggage just gets in the way.  It slows you down and costs you while doing so.  Personally, I didn’t have an appreciation for traveling light until I noticed that my business colleagues saved so much time because they never went to the baggage claim or had to wait plane side for their luggage to be brought to them.  After making this observation, I decided to always travel as light as I could regardless of where I was traveling to.

I’ve also found that we can carry excess luggage along as we travel in life.  Things, people, status, circumstances, ideas, beliefs etc etc can often become (excess) luggage that slows us down taxing us physically, emotionally, socially and spiritually.  I think it’s important to take a step back and examine our luggage.  It could be that our job has become excess luggage and its time to find a new one. It could be that some beliefs we hold dear are now excess luggage and its time to discard them.  It could be certain habits that we’ve picked up along the way that we need to let go of.

Take a moment to look at your life.  Are you walking around with excess luggage?  Now may be the time to let go of it.

Doing Wrong Things Righter

It was the fall of ’98 and I had been in the United States for barely over a year.  It was the beginning of a new semester and I was looking forward to seeing a friend who had been away for the summer. When we finally met, I was  excited and happy and wanting to let her know that I had missed her and that she looked good after the long summer break I proceeded to say:

It is so good to see you, you look so healthy.  It looks like you gained some weight!

Now, before you judge me, you’ll need to understand that I had lived in Nigeria (for a long time) leading up to that and at that time, in Nigeria, telling someone that they had gained weight (which was very different from telling someone they were overweight) over the summer was a compliment – it meant that they had a good summer break.  The school year was stressful and difficult and most of us ending looking a bit worn for wear by the time summer holidays came around.  I was innocently doing something I considered right.

Nonetheless, she wasn’t too pleased with my observation and so I proceeded to tell her what I meant, explaining to her what the compliment would have meant in Nigeria.  Well, as you can imagine, that only worsened the situation.  The more I talked, the worse it became.  Eventually she just walked away.  It took weeks of profuse apologies to get back into her good graces.

Whenever I remember that experience, I think of the Russell Ackoff quote:

The righter we do the wrong thing, the wronger we become.

I had initially said the wrong thing but in trying to right the wrong with my explanations, I just ended becoming wronger.

In knowledge work (and other types of) environments, “doing wrong things righter” is prevalent. It is almost the order of the day.  Many solutions are simply local optimizations with the wrong focus.  When we discover that they are not working and we try to improve (our wrong) solution, it makes the solutions even wronger. These solutions end up hurting both people and our economic goals. Examples of such “wrongs” in product development that I have observed include:

  • Having different roles in a challenged software delivery team fix their problems in isolation
  • Add more QA checks and inspections to prevent defects
  • Improving the estimation of things that shouldn’t be estimated in the first place.
  • Big design upfront in an attempt to lock down things (Agile teams are guilty of this as well, just in smaller time boxes)
  • Top-down driven policies to combat quality issues
  • Adding more layers of management because people need to be managed
  • Adding more people to a team so that things can be delivered faster
  • Scaling – I won’t even go there
  • Etc etc etc

(For the non-product development people who read this blog, I’m sure you can find similar items in your domains.)

So how can we avoid doing wrong things righter?  Well this goes into field of Systems Thinking and I’d encourage you to explore that.  But real quick, here are some thoughts:

  • Be open to the fact that you may have been doing the wrong thing the entire time
  • Understand the problem – the true problem and not just symptoms or side-effects. 5 Why’s can be valuable here.
  • Understand the system or systems in which the problem was discovered – don’t look at things in silos or parts. Be holistic in your approach. Understand the network of interactions; the value stream of work.
  • Attempt to dissolve (not solve) the problem if you can – this means remove the conditions that create the problem in the first place. Design new systems and structures.

Don’t get caught up in efficient ineffectiveness.  Don’t do wrong things righter.  Focus on doing the right things.  It’s easier said than done, but it is the right thing!