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.
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.
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.
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.
In the next part we’ll cover the science of economics.
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.
[…] Kanban is more than a board with sticky notes on it, and moving cards across a board is completely orthogonal to the ideas of reducing waste and eliminating points of delay (James Shore and Arlo Belshee have a number of insights on this in their Single Piece Flow in Kanban talk). Engineering kanban is also designed to reduce multitasking and get things completed more quickly by giving your workers slack time. […]