“We’re good at saying yes.” – Feedback from an overloaded organization challenged with prioritization. In today’s overloaded world, you aren’t effectively saying “yes” to anything unless you say “no” to something else. In knowledge work, especially software development, the capacity of an organization to deliver solutions is very abstract and difficult to quantify. Since knowledge requests aren’t really tangible (they are abstractions of desired functionality), it is difficult to see the impact of adding a feature request to a list of requirements, or adding another project to a portfolio of projects.
Let’s look at the often-used example of highway traffic. Picture a mile-long stretch of Interstate with three lanes of traffic. At the end of the one-mile stretch, we put up cones and reduce the lanes from three to two. You will soon notice you can fit a lot of parked cars on that stretch, and that represents our fixed capacity (maximum number of cars that can fit). Maximize Capacity Utilization…? But notice if we measure the number of cars reaching a point past the merge zone over time, we’ll get a reasonable throughput measured by cars per minute. Now let’s start a simulation where we gradually let cars enter the empty highway. Early on we are in a phase where the throughput (cars per minute) increases for every car added. If the cars are limited by law to 60 mph, then the average waiting time for each car on the mile stretch is one minute. This falsely leads us to believe that we can always add more and more cars and get more and more throughput (cars per minute) across our stretch of highway, which is true…for a while.
…or Minimize Waiting Time? HOWEVER, way before we reach 100% capacity of cars that can fit on the mile-long stretch, the throughput stops increasing, and what’s worse, the average waiting time starts to increase, but the throughput just past the bottleneck is still high! You’ve been there—the phantom event somewhere up ahead makes you come to a screeching halt and the dreaded, stressful traffic jam emerges in front of you for no apparent reason. This is also the fallacy of focusing on throughput. We can be fooled by a high throughput number at the expense of waiting time. This is very important—once we approach the capacity limit of the highway, the wait time for any new car entering the highway increases. What does this have to do with knowledge work and capacity? We tend to treat knowledge work capacity like an uncrowded highway, where we can add a car, increase throughput, and not impact waiting time. The Lean value stream is our “knowledge work interstate.” Its purpose is to bring visibility to the work required to get from initial idea to a solution consumed by the customer. Now consider two software delivery organizations. One bundles up feature requests into annual projects that deliver 60 features at the end of the year. Another organization can deliver with the same annual throughput, but does it in batches of five per month. Both have the same annual throughput of 60 features per year, but which is better? No matter how valuable any individual feature request is in the first organization, the soonest it can get through the system is one year. The second organization could feasibly get any feature request done in a month from the time it was requested. Yet both have the same annual throughput. Lean thinking guides us to view the value stream from the customer’s perspective, with a premium being placed on how long the customer waits from the time of the original request. Managing queues and not overloading knowledge work capacity helps flow and wait time. Instead of focusing on throughput, the right question to ask is what is the highest business value that can be delivered in the least amount of time. This simple change in perspective is to see the true measure of productivity, which is the time required to get any one request through the system. So what are the key lessons and how do you apply them in your shop?
|
