A Taste of Lessons #11: Agile Practices

Posted on September 09, 2012 by admin

Today’s extract from Lessons in Agile Management republishes a classic from 2005. This post was inspired by the then emerging and now infamous XIT sustaining engineering implementation of a virtual kanban system at Microsoft. It’s at the root of the myth that you don’t estimate in Kanban. Such dogmatic, context free guidance has never been part of Kanban. The truth is that effective Kanban implementations will have people who make considered decisions about the economic and risk management value of estimating and decide whether or not it is appropriate for any given type of work or class of service.

Calling out estimation as waste was always going to be controversial in the Agile community. I was threatening one of the sacred cows. A defensive tribal reaction was inevitable. Seven years later, it still provides ammunition for those who would argue Kanban isn’t Agile!

Why Estimates are Muda

First published on September 27th, 2005

I’m getting 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 softwareengineering community either—their Personal Software Process/Team Software Process (PSP/TSP) method is based around estimating and then tracking estimates against actuals. My dislike for earned value reporting isn’t too popular either—particularly as the American government mandates it 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 the velocity of clientvalued 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 this is what 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. Even if it isn’t, we wouldn’t want to waste slack capacity that 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 capability. We lower our capability on an activity that 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 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 that anything you learned from the estimating process is lost. It gets worse. Often we estimate work that gets cut or doesn’t get done at all because the estimate is too large. Calculating a time-ontask 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 Feature-Driven Development, we analyze the work into a domain model, and later we 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 that is entirely value-added. All the work done analyzing for the Feature Plan is value-added. It creates knowledge that 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.

So, to be clear—I am all for analysis that produces knowledge we can use in the customer delivery. I am against estimation that produces information that is not of deliverable value to the customer!

Analysis Rather than Estimation

First published December 18th, 2005

I’ve noticed some confusion over the difference between estimation and analysis. When I’ve suggested that we stop estimating and focus on analysis, some people have struggled to understand the difference. Again, when I suggested that all estimates are muda, but continued to encourage the use of analysis, some people struggled to understand the difference. So, I decided to look up the dictionary meanings for clarification.

Verbs first:

  • to estimate: to calculate approximately (the amount, extent, magnitude, position, or value of something)
  • to analyze: to examine methodically by separating into parts and studying their interrelations

Now, for the nouns:

  • estimate: a tentative evaluation or rough calculation, as of worth, quantity, or size; a statement of the approximate cost of work to be done, such as a building project or car repairs
  • analysis: the separation of an intellectual or material whole into its constituent parts for individual study; the study of such constituent parts and their interrelationships in making up a whole.

It is clear that estimation is about quantification of cost, whereas analysis is about the decomposition and integration of a set of parts. Analysis adds value by creating knowledge about what components we need to create and how they integrate together to synthesize a whole solution. Estimation merely quantifies the cost. I believe that in our industry, people are lousy at estimating. And that this may indeed be true of all knowledge work. Estimating knowledge work is hard. It’s even harder without proper analysis. However, reliable and repeatable analysis techniques—although they exhibit variation, and are seldom used perfectly— significantly contribute to our understanding and planning of software development and project delivery, do exist, and should be used. Analysis reduces variation and makes plans more accurate. Estimation does neither of these things. Agile estimating, on the other hand, uses historical productivity data, and it uses the output of analysis to provide a reliable estimate with a buffer for variation. The result is a plan that is more accurate, and the time spent on it was value adding, knowledge creating, and decomposition and integration, rather than inaccurate, non-value added cost quantification.

Comments: