Kanban is the japanese word for signalling card, but a signal for what? In the 1950s a Japanese delegation including Sakichi Toyoda (founder of Toyota) and Taiichi Ohno (on of the masterminds behind the Toyota Production System) went to
the United States to observe how Ford was mass producing cars. They were not impressed. During a stop at an american supermarket they witnessed how items were automatically resupplied once sold. The beauty of this concept was its ability to ensure a sufficient number of items was available to customers, without having to bind too much cash in unneeded inventory.

Reading the InfoQ newsletter the other day, I found that "Kanban is the hottest buzz since the dawn of XP" (eXtreme Programming). It is really so? Kanban is great for limiting queues of items with a certain level of uniformity - but does software requirements fit that? We certainly have queues of work that needs to be controlled - and requirements certainly can be described in a somewhat uniform way. The question really is - before implementing a kanban system to limit work-in-process, do you know for a fact that this is your biggest issue? I look forward to see kanban systems implemented in software development organizations where highly varying task size, complexity and context is addressed effectively.

By Sune Gynthersen

At a retrospective meeting with a client not to long ago, a really interesting point came up. The client had deliberately attempted to push a lot of feature work onto the development team, while keeping a fixed deadline - presumably to have the team work harder, and thereby producing more features before a particular deadline. Interestingly quite the opposite happened.

A total of 7 features were requested by the customer, while neither deadline nor scope change could be tolerated. The result? 7 features were reported done on the deadline. Unfortuately it turned out - in production - that only 2 was working as supposed, meaning that 5 was more or less defective.

When these numbers were clear to everybody an obvious question came up. Could the team instead have aimed for a total of 4 features (instead of 7), and actually completed 4 features upon the deadline (instead of 2)? Significant amounts of time had been invested in 5 features that were not completed anyway.

Who were to blame for this? The development team were only doing their best, trying to accomplish a goal not set by themselves. How could the client know any better? They did not know the kind of problems that are induced by using a push approach.

What the client and the development team had experienced was simple physics.

Little's Law:
Work in process = Flow time * Throughput

Little's Law describes the relationship between multiple key variables in any value stream (including software development projects)

What Little's Law says, is that - The more work you start, the longer it will take you to finish (given that your capacity/throughput is stable). Now imagine what happens if the customer asks for a fixed deadline - The amount of work that can be done before that deadline is indicated by the current capacity.

How about if we attempt to get higher throughput/capacity by increasing the amount of work, and asking people to work harder. Which variable do you think will be affected? ..you guessed right, Flow time will increase, as throughput (or capacity) does not increase magically over night.

I wonder how many people in the software industry are trying to outrun Little's Law, by putting pressure on the "floor" workers (e.g. developers and testers) ?

Lesson learned?
1) Don't try to run above the speed limit indicated by your current capacity. You will pay more and get less.
2) Favor pull systems over push - for instance as advocated in Scrum.
3) Never attempt to fix scope if you have a fixed deadline.

By Sune Gynthersen