How does "kanban" for project management relate to kanban in manufacturing?

Question

I recently learned about kanban here and followed some of the links and read some of the recommended sites and PDFs.

It looks interesting, but one thing keeps confusing me.

In its original sense, the kanban method is about signaling production needs as part of a complex manufacturing process, with the basic goal being to optimize production by using "pull" signals rather than push. A big focus is on keeping inventory levels from ballooning when they needn't.

The current project-management sense seems to be about using a board with limited slots in each position (for example: to-do, on dev, on qa, release). These slots fill the limiting function of the kanban cards in the manufacturing process (while the cards in the slots are sort of like the manufactured product).

To my limited understanding, the latter seems to be basically using the former as a poorly-aligned analogy; the similarities are that both have just-in-time as a goal and both focus on limiting work (but in a very different way).

Am I missing something that ties the two together, or is it fair to say that the kanban project management methodology is named after the lean manufacturing concept but is not really the same thing?

Answer 1

You aren't missing something. Analogy isn't that direct, although on both worlds we use the same roots.

In IT world we don't really deal with inventory whatsoever. What more, contrary to manufacturing, we don't build the same thing (a product) over and over again. Instead, we build new features, different from everything we built before.

However the basic concept is the same: we don't want to have too much work in progress. You can use a following analogy. You don't want to have too many unfinished cars in a factory as it costs you money to store them, it also cost you money to buy all the parts, and you can't possibly sell them.

By the same token you don't want to have many unfinished features in your project as they raises complexity of a code base, raise maintenance cost and make it harder, and more expensive, to deploy. And obviously unfinished features don't bring any value whatsoever to customers so you can't possibly sell them.

It also appears that in both cases limiting work in progress, and fine-tuning these limits, improves throughput meaning the whole unit/team/whatever is more productive.

We can refer to the name itself too, which means signboard and it exists in both worlds.

From this perspective I see the same source for both concepts even though in details their implementations differ. However it is pretty much expected as in IT we don't really deal with the physical matter.

In short: Kanban for IT (I don't set a limit for software development only) and for manufacturing are different tools, even though they're named identically. However I'd be very far from naming it "a poorly-aligned analogy."

Answer 2

In addition to what @Pawel Brodzinki has said, I'll explain how the signalling works:

In its original sense, the kanban method is about signaling production needs as part of a complex manufacturing process, with the basic goal being to optimize production by using "pull" signals rather than push. A big focus is on keeping inventory levels from ballooning when they needn't.

In a software kanban, our signal comes from the "holes" on a Kanban board - the gaps in which the limit hasn't been reached, which "pull" further work through. If we were to put a big red card in each hole or slot, that would become our signal card.

Contrast this with other board approaches, in which work is pushed through to production, and a developer can keep coding even when testers are overwhelmed. In a kanban system, developers see the problem and can go to help (and analysts can become testers, etc.)

In a production system, we're trying to limit the amount of inventory and get things through to a finished state as quickly as possible.

Done well, a software kanban system lets us limit the number of things on which we haven't got feedback. I find the assumption that we're trying to get things into production quite dangerous in software development, as it's too easy to produce the wrong thing, especially in climates where we no longer do the massive up-front work of Waterfall-style analysis. Our goal is to get the right thing into production, as quickly as possible, until we have enough feedback that it's good to move onto the next thing.

The longer we spend without getting feedback on the work we've already done, the more our knowledge degrades and the harder it will be to adapt to that feedback once we receive it. This is the equivalent to cars rusting away out in the lot. We can't maintain knowledge half as easily as cars, which makes the kanban signal and the faster throughput it creates even more important and relevant than it is in manufacturing.

Answer 3

A direct answer to your question might be found on InfoQ.

A Kanban1 is a physical card used in Toyota Production System (TPS) to support non-centralized "pull" production control. It has spread to the manufacturing industry all over the world as a tool of Lean Manufacturing. Now in Agile software development the visualization of projects, such as posting task cards on a wall, is a commonly seen practice, which is sometimes called "Software Kanban", or "Task Kanban". Now we even see some product maintenance teams utilizing Kanban systems in a waterfall-like process model. So what is Kanban? Why is it used in the context of software development?

In this article, I first explain what a Kanban system is in the context of Lean manufacturing, especially in TPS, and gather insights from the practices and principles in that mature industry, identifying concepts that can be applied to software development. Secondly I look around our software development projects and point out examples of Kanban applications. Then, I analyze commonality and differences between Kanban systems in production and in software development, and try to give ideas on how to effectively apply Kanban system to software development, including an introduction to the recent movement of "KSSE - Kanban System for Sustaining Engineering" emerging on the kanbandev 2 discussion list. Finally, I give a big picture of TPS, the original context for which Kanban's use as a tool, and from which software development can still learn more.

Read More