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…..
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”
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.
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
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.
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!
I often hear/read people talk/write about how Agile is a mindset and how it should not characterized by a set of practices. It’s been said that “confession is good for the soul”, so I’ll confess that I find myself making such statements and while I wholeheartedly believe that Agile is largely a value system, its important not to throw out the baby with the bathwater. My observation and experience is that doing so results in teams and organizations (and consultants) implementing whatever they want.
Anyone who has formally learned to play a musical instrument or a sport or art or craft (you get where I’m going) knows we start with learning the fundamentals (which includes practices). For someone learning to play the piano, you need to know where middle C is, the difference between black and white keys, you need to understand and be able to play scales, understand and play 1-3-5 (chords) etc etc. There is a set of fundamentals that you need to have if you intend to be able to play music (that is pleasing to the ear).
Once you have the fundamentals down, you become empowered to improvise and try new things on your own. To take some risks. To do something different. You can do this because the fundamentals form the basis of any improvisation that you do. You build upon the fundamentals. You may also recognize this as Shuhari.
So what are the fundamentals for a team who says it’s Agile? Based on my experience, I would say they need to able do the following:
- Attend to the needs of everyone involved (see Antimatter principle).
- Deliver value in small increments
- Deliver value frequently
- Respond to change quickly
- Learn regularly
(As a side note, don’t try “scaling” – whatever that means – if your teams don’t have a handle on the fundamentals).
Whatever you do, make sure you know what the fundamentals are and practice them till you’re really good at them. Then go from there.
This is a follow up post to How Long Will It Take. I often read that we need to know the “all in cost” before embarking on an initiative. I’m not sure at what level this rule applies at i.e. the program, product or feature level etc etc. I do however disagree with that position. I agree that sometimes its needed for decision making re how valuable are your estimates.
Over a decade ago, I was tasked with the programming language/technology platform conversion of a large supply chain system. It was a change we needed to make in order to remain relevant and stay in business. Both the platform and language were brand new to all of us and we had very little knowledge as to what the conversion would really entail for this complex system. Yet this was something we just had to do or we’d be out of business, remember?
I was asked to estimate how long it would take to complete this assignment and I tried my best (with a lot of preliminary research, long discussions with the company that was retiring the language/platform and searches for other companies who were doing the same thing) but at the end of the day the upper bound of my estimate range was still too low. I will accept that I could have possibly tried harder or used better estimating methods but given how much was not known, I question how valuable the estimates would have been anyway. Would they have really reduced uncertainty? Would the reasonable uncertainty range have provided much value? Did we need an estimate to decide to port the solution suite? I daresay that even if I had come in under, it would have been a result of luck or pushing the team to the brink and not the estimating procedure (but no one makes their teams make sure they come in at the estimate, right?)
In full disclosure, several months into the conversion, we did become good at projecting how long things would take. But this was a result of a ton of experimentation and learning that we had acquired after a couple of months of working through things. We now had historical data and experience that we could reference when asked “how long”. Based on my experience, it seems quite obvious that we often need to experiment and learn first and then and only then can we attempt to estimate effectively (if we still need too). It would seem that there are those are uncomfortable with the notion of getting paid to learn or discover. I think this gets to the heart of some of the debate surrounding #NoEstimates i.e. a disagreement about the nature of the work we do or how much do we really know at the onset. I, based on my experience, believe that learning and discovery reside at the core of product development. It’s knowledge work. Maybe that will change with time, we’ll see.