My #NoEstimates Apology and Epiphany #NoInventory

I was lucky enough to discuss ideas and thoughts with Woody Zuill last week on No Estimates. To be fair, I wrongly assumed that an upcoming No Estimates workshop was somewhat monetizing the No Estimates ideas. After talking to Woody, it became very clear that this was something requested by people interested in hearing Woody and others speak. It was not initiated by the No Estimates movement and my assumption was incorrect. Just goes to show you than you should always seek to understand first.

For this I apologize.

To Woody’s great credit he still agreed to meet with me over Skype and agreed to talk about Software Development and share ideas. It was a great session with many ideas shared about pains and gains we both had seen on Software Projects over our many years.

No Inventory

About halfway through on conversation we started to discuss projects where I had to estimate. I discussed how I felt the estimates were required but also that I saw the draw backs of estimating. I also felt the clients liked the estimates and I confessed that I actually like the estimates as well. Then I made an observation. The more inventory one had on a project, the more detailed your estimates were. Whether that inventory be documents or code, there certainly seemed to be a linear or possibly even exponential relationship.

For example:

  • If you can deliver in less than 2 weeks, estimates are not even required
  • If you can deliver in less than 2 months, deliverable level estimates are enough
  • If you can’t deliver in less than 2 years, break out the Work Breakdown Structures, Gantt charts, and earned value calculations

Epiphany

Then it really struck me. (and I think both of us) Yes we would like to reduce, minimize, or eliminate the requirement for estimates. But that can’t be done in isolation. We can’t take an ERP implementation that will be implemented in 3 years in a big bang method and say we don’t need estimates. Why? Because the business needs to make decisions for that three-year period and budget decisions. No Estimates can’t happen in isolation. When we propose No Estimates, what we are really proposing is No Inventory. Once we have No Inventory, we will lessen or perhaps eliminate the requirement for estimates.

You see it is quite ridiculous to propose to eliminate estimates when a project has a huge amount of inventory. The business requires them to make decisions and predictions because they won’t see the results of the inventory for a long time. But if we could turn that inventory over in a more timely manner, one of the main needs for detailed estimates goes away. I’m not saying that the estimates totally go away, but they certainly become less detailed and less critical.

For me what this epiphany meant is that instead of talking No Estimates, I’m going to talk about No Inventory. On all my projects the question is going to be how can we go to production quicker and faster. If we can do that, I believe our estimate will become less detailed and the estimates may perhaps even disappear once we are delivering fast enough.

For my projects, I’m not sure estimates will totally disappear. But the goal to keep them at a deliverable level by delivering early and often is a step in the right direction. The other advantage to minimizing inventory is that it also minimizes the size of the estimates and the risk to the project. If I miss the estimate on a two-week inventory, no problem. I can learn and fix it in the next two weeks. If I miss the estimate on a two-year inventory, now I have a problem.

No Inventory

8 thoughts on “My #NoEstimates Apology and Epiphany #NoInventory

  1. Great post! And I agree. Focus on delivering something usable as fast as possible.
    I wonder though: how can we lessen the inventories? We can’t possibly work on everything at the same time. So, if we have lots of projects (inventories) in the pipe, we kind of still need to estimate those, right?
    And another thought: even deliverable level estimates can be used dysfunctional and create pressure and lower quality. So, IMO, the size of the estimates doesn’t make them less dysfunctional, maybe just less “sensible”. But at the same time, the idea behind an estimate is not to be “sensible” or not.
    Any thoughts?

  2. I agree with your comments and thoughts. I think you hit it on the head. The question should be how we can lessen inventories. I think we will find once we lessen inventories, the need for estimates also disappear.

    Ideally, we don’t want projects in the pipe. We want to work on small pieces of all of them at the same time. But sometimes that may not be possible and we may need to estimates, but we should always ask how we can prevent the inventory from being created or added to…

  3. Great post. You are the second person to link #NoEstimates with #NoInventory this week! 🙂

    I would like to add that the idea of reducing inventory is at the core of Agile (early and often delivery of working software). And I agree that a direct consequence of low inventory is low risk+reduced need for estimation. The reason is simple: we *see* progress all the time, therefore we don’t need to estimate.

    But this is not the whole story. I would call your attention to the work by Deming and Ohno: systems have an inherent capability, and #NoEstimates calls on us to understand that capability instead of estimating it.

    Work like Critical Chain Project Management was a great step forward in focusing on capability improvement instead of estimation (although they never removed estimates, they tweaked them to reduce their negative impacts).

    So I would challenge you to think more although out how can you improve the capability of your system of development instead of trying to justify the use of estimates in some cases. If you don’t understand the capability of the system, estimates can only mislead you (plenty of data to that effect).

    How can you measure the capability of the system you work within?

  4. The work “all” is loaded. Incremental delivery of capabilities, l like the picture is not “big bang.”
    The notion of “no inventory” begs the question of what kind of projects are those? The answer to that may be the key to categorizing when the need to estimate to attributes of the project are applicable.
    Seems the #NE thoughts have turned to #NInv which actually makes sense. but leaves open the where applicable question. This is similar to the Kanban question. Single Stream projects, perfect fit. Multi-stream not so much if at all.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s