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.
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.
- 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
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.