Tuesday, September 27, 2005

Why Estimates are Muda

I get a reputation as a Bad Boy of project management! My advice to stop estimating doesn’t go down too well with the traditional PM community. It doesn’t sit too well with some of my new friends in the traditional software engineering community either - their PSP/TSP method is based around estimating and tracking estimates against actuals. My dislike for earned value reporting isn’t too popular either - particularly as it’s mandated by the American government for certain types of contracts. [I’m not overly fond of Scrum burndown charts either - when they are based on time on task estimates rather than customer valued work items like user stories] My agile estimating technique based on velocity of client valued work items seems natural to me. It seems like the agile way. The simple, easy to calculate way. The doesn’t-waste-any-time way. And it’s this that I want to talk about today - doesn’t waste any time! Traditional estimating is muda! Agile estimating isn’t! Here is why…

Let’s assume that software development is the capacity constrained resource in our organization. It often is! Even if it isn’t we wouldn’t want to waste slack capacity which might otherwise be used to absorb variation elsewhere in our system. When we spend time estimating something, and we use the capacity constrained resources to do the estimating, we effectively lower our capacity. We lower the capacity on an activity which isn’t client valued. The customer doesn’t care how long your estimate for a task was. Doing the estimate often takes a significant chunk of the time compared to the time it would take to do the work. Doing the estimate even a few days but more likely a few weeks or months and in some cases years before the work is done means anything learned from the estimating process is lost. It gets worse. Often we estimate work which gets cut or doesn’t get done at all because the estimate is too large. Calculating a time on task estimate doesn’t create customer valued knowledge. Estimating is non-value added. Estimating is muda!

On the other hand, I thoroughly embrace the idea that we analyze and partition our problem space. In FDD, we analyze the work into a domain model and later partition it into components. We further analyze the work into Features and group them into Feature Sets and Subject Areas. All of this analysis work gives us a work breakdown structure which is entirely value added. All the work done analyzing the Feature Plan is value added. It creates knowledge which is used to deliver the customer valued functionality. We then estimate based on feature velocity. An agile estimating technique that takes almost no effort to calculate. Agile estimating based on analysis minimizes waste of capacity in the capacity constrained knowledge worker resources.

Just one more reason why agile methods deliver better economic returns than traditional software engineering and project management methods.