is driving the need for them. It will become clear that the root cause involves delays, and that is what we want to eliminate.
Re-doing requirements is a common practice in software development. It occurs because we often get requirements too early. There is a delay between when a requirement is first mentioned until the development team starts working on it. Inevitably, the requirements will have to be updated or redone; otherwise, we will have another activity, working from old requirements , which clearly causes wasted effort.
Consider “fixing” bugs . The quotes around the fixing are intentional: although most developers believe they spend a considerable amount of time fixing bugs, in reality they spend more time looking for the bugs. This is not just semantics. Imagine a developer who writes a bug but is immediately told about it. She can probably fix the problem fairly quickly. Now, consider the situation where the same error occurs, but the developer is not told about the problem for 2 weeks. It will take her considerably longer, even if nothing else changed. It is even worse if it falls on someone else to fix it. Where did this new work come from? It comes from the delay between creating and detecting. I call this “induced work” because it is caused by delay: Just like moving magnets induce electricity in wires, delays induce work in development.
A similar phenomenon happens with “integration” errors. Virtually every “integration” error I have seen in my years of development has been caused either by communication errors between two groups or one group not doing what they said they would do. While such an error is detected at integration, it doesn’t make it an integration error.
Note how all of these “wasteful” items, including building unneeded features is exacerbated by delays in information or in people being available. Overbuilding frameworks is perhaps the only item in the right-hand column that is not caused by delays.
Let’s look at the work in Table 1 again. How much time do you spend on the left hand side and how much on the right hand side? Seriously, stop and think about it a minute. In my classes, when I ask people this question, people tell me they spend between 30 percent and 70 percent of their time on the left hand side, doing useful work. This means that between 70% and 30% of the time is spent on the right hand side, doing work that is essentially useless!
Now, we can speed things up either by doing the work on the left hand side faster or by figuring out how not to do the work on the right hand side at all. While you might be able to do the work on the left hand side faster, with the exception of automated testing, it is not likely you will realize significant improvements doing so. On the other hand, getting better (faster) feedback and having the right people work on the right tasks at the right time can virtually eliminate most of the work on the right hand side.
Shift your focus from productivity to working on the right things at the right time with the right folks. Better productivity and lower costs will come as great by-products. How to do this in software development is exactly what Kanban focuses on.
Working on the Right Things at the Right Time
So how to shorten the delays involved in our work? In large organizations I would assert that we must include the work done prior to the development teams. We can think of product