The Science of Kanban – Process

This is the third part of a write-up of a talk I gave at a number of conferences last year. The previous post was about the science of people.

Even though a kanban system describes knowledge work, we can still apply formal sciences such as mathematics. Rather than applying them at a detailed, micro level, we can take a system approach and apply them at the broader, macro level. As an example, if we try and predict the result of a single coin toss, we are only able to do so with 50% accuracy due to the unpredictable, random nature. However, if we to try to predict the result of 1000 coin tosses, we can be more accurate, albeit with less precision and some degree of variance.

Queuing Capacity Utilisation

The most common mathematics used with kanban systems is associated with queues and utilisation. Queuing capacity utilisation suggests that as capacity utilisation increases, queues increase exponentially. Thus extremely high utilisation will result in large queues.

scotland_karl_06

Further, Little’s Law tells us that the time something is in a queue (lead time) is equal to the size of the queue divided by the processing rate.

Lead Time = WIP / Processing Rate

It follows then, that if we want to complete work quickly (i.e. with a short lead time), then should reduce queues, which requires reducing utilisation. Reducing utilisation too much, however, will begin to have diminishing returns.

Traffic Flow Theory

Traffic Flow Theory gives an explanation as to why a work-in-process limit on one may be too low.

scotland_karl_07

Originally observed by Bruce Greenshields in 1934, Traffic Flow Theory describes how, as speed (in miles per hour) goes up, the density of traffic (in vehicles per mile) goes down, and vice versa. This is observable on roads with a low density of cars (i.e. empty) which are able to travel at high speeds, and roads with a high density of cars (i.e. gridlocked and bumper to bumper) which are stationary. Flow is defined as the product of speed and density, and thus there is an inverse u-curve, with high flow in the middle, and low flow at either end due to either low speed, or low density.

For product development, density can be viewed as work in process, speed correlates to lead time, and flow correlates to throughput. If work in process is too low for the available capacity, then lead time will be short, but throughput will be low. Similarly, if work in process is too high for the available capacity, then lead time will be long, and throughput will be low.

An interesting effect happens on either side of the flow curve.

On the left side, if density is increased (increasing work in process), speed decreases (increasing lead time), and flow decreases (decreasing throughput). The decreased flow causes a further increase in density resulting in a negative reinforcing loop.

However, on the right side, if density is increased (increasing work in process), speed decreases (increasing lead time), and flow now increases (increasing throughput). The increased flow causes a decrease in density resulting in a balancing loop.

Thus, while the optimum density is unlikely to be achieved precisely, it is better to be on the right hand side, with slightly less work in process, where a slight increase will balance itself out.

Feedback

It’s generally recognised that software development is a non-linear activity, due to the many feedback loops, so it’s useful to understand the effect that the feedback loops have on a process.

One of the impacts that a feedback loop has is related to its delay, where a long delay can lead to instability and oscillation. Taking a shower as an example, if when trying to turn the heat of the shower up, there is a long delay between turning the tap and the water temperature increasing, the natural reaction is to turn the temperature tap further. Eventually, when the change in water temperature comes through it will be too hot. The same can happen again when trying to turn the heat of the shower down again.

scotland_karl_08

Thus it is a good idea to minimise delays in feedback, or put another way, have fast feedback. Fast feedback also results in smaller queues, because less work builds up waiting for feedback. Smaller queues result in less work in process, and we have seen that lower work in process leads to shorter lead times. Shorter lead times further generate faster feedback, resulting in a positive reinforcing loop.

scotland_karl_09

In the next part we’ll cover the science of economics.

Rating: 4.9. From 7 votes.
Please wait...

2 comments on “The Science of Kanban – Process

  1. You are batting 1000 with this series so far. Carefully crafted feedback loops is the number 1 way to improve your software development efforts. It’s not how much you know now, but rather how rapidly your perceptions line up with reality. It’s amazing how often our intuition is wrong in all sorts of areas: the market, requirements, technology, and what makes the most efficient process. Often, the software development process folk lore is not nuanced to cover your situation… or just flat wrong.

    However, this is one area where I think Scrum provides more guidance than kanban. What I like most about Scrum is that it gives us a concrete example of carefully designed feedback loops that shit the emphasize to product over the process feedback and give us light weight rapid feedback on the plan.

    The one aspect of feedback that I think gets too little discussion is the balancing of qualitative and quantitative feedback. We implicitly bring forth the advantages of qualitative feedback when we push decisions closer to the folks doing the work, but the “science” that makes that a good thing, is embedded in this proper balancing of insight from humans against insight from numbers.

    Another nice thing about this post, “Traffic Flow Theory gives an explanation as to why a work-in-process limit on one may be too low.” The general vibe that I hear is that lower is always better when talking about WIP. That’s certainly true of new teams but I think we are now starting to see mature teams where a nuanced understanding of the tradeoff is necessary. We should stop telling folks, lower is better and start explaining the tradeoff better.

    No votes yet.
    Please wait...
  2. Pingback: A culture that attracts quality candidates | Recursive Erudition by Josh Rivers

Comments are closed.