Skip to content

Estimates Are Not Commitments But…

August 20, 2014

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

August 14, 2014

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

August 14, 2014

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

August 7, 2014

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!

 

Those Pesky Fundamentals

July 30, 2014

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.

How Long Will It Take – Part II

April 1, 2014

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.

How Long Will It Take?

March 27, 2014

“How long will it take?” is a question that gets asked often in many spheres of life.  Sometimes, we are able to answer immediately because “it” is something that we’ve done time and again.  For example, if you ask me how long it will take me to prepare jollof rice, I can answer that immediately.  Sometimes, there is a delay in our answer because we don’t know but know someone who does.  For example, if you ask me how long it will take to make biryani, I’ll need to go look up a recipe and figure what the recipe says about how long it (should) takes.

But what happens when we don’t have or can’t get to the information?  What happens when the range of answers is so wide that its of little value?  What happens when we simply don’t know.  For example, as a music writer and composer if you ask me how long it will take me to write and compose a new piece, I won’t have a good answer for you because I really don’t know.  It could be just me but in talking to friends who are involved in creative-type activities, I’ve come to observe that its hard to determine how long a creative act will take (except you are copying someone/something else).

So how do creatives get things done?  How do I end up finishing a piece?  How did you get your term papers done?  How do you finish writing a book?  Deadlines.  Deadlines are what keep this creative in check.  Even when I finish early, its probably because there was a deadline of some sort. Without deadlines, I would probably write a single piece for six or seven months. But when a friend says they need a song for their wedding in the summer, I know I need to constrain myself.

I have experienced software development as being highly creative endeavor.  I imagine that some feel and have experienced differently. In my professional career, I have tried to avoid situations where there is not a lot of creativity and hence I find that it is often very challenging to answer the “how long will take” question in a valuable way when it arises.  So I usually ask for a deadline instead – as a side note, very often there is no deadline, it just happens that someone has a need to know how long just like I want to know when an Arsenal player will come back from injury – and then the team works towards that deadline.  Working towards a deadline has some interesting side-effects as well but that is beyond the scope of this post.

But just like with most things in life, please use deadlines responsibly.  Understand that a deadline that is too aggressive can kill creativity and your product. And while we’re at it, please don’t turn an estimate into a deadline.  Thanks!

 

Follow

Get every new post delivered to your Inbox.

Join 253 other followers