It wasn't just coming up with a system that works for software and taking a cool name from manufacturing processes.
The methods in IT were built on the same principles (and, to a degree, values). It's just the implementation is different. In fact, in software, we emulate some things that are given in manufacturing. A notable example is making work visible. On a factory floor, piles of parts are clearly visible. The code in progress is not. Thus, we have index cards representing queues of work (piles of incomplete parts).
The approach to limiting work in progress is actually the same. Again, the solutions differ (replenishment triggered by visual cards in manufacturing versus numerical WIP limits on visual boards in software), but the outcome remains very similar.
There are differences, of course. The big one is how we react to variability. While in manufacturing, we, well, manufacture a lot of identical things, in software, each item is different. Thus, on a factory floor, we aim to control and reduce variability, while in software, we tend to accept and work around it.
There are other differences in flavor, too. Like in knowledge work we don't stress too much about waste reduction, while in manufacturing, it's a big theme, etc.
However, if we look at the ideas and not specific implementations, these systems are very similar. And I'm saying it as someone who trained people in that domain both in knowledge work and manufacturing.
Not that any of this helps with confusion in the naming. Even less so given the fact that some people are arguing the seemingly fundamental differences between using kanban (lowercase k) and Kanban (capital K). I guess people are people.I don't much care. As long as someone can explain what they mean by it, I'm fine with whatever naming they come up with.
The methods in IT were built on the same principles (and, to a degree, values). It's just the implementation is different. In fact, in software, we emulate some things that are given in manufacturing. A notable example is making work visible. On a factory floor, piles of parts are clearly visible. The code in progress is not. Thus, we have index cards representing queues of work (piles of incomplete parts).
The approach to limiting work in progress is actually the same. Again, the solutions differ (replenishment triggered by visual cards in manufacturing versus numerical WIP limits on visual boards in software), but the outcome remains very similar.
There are differences, of course. The big one is how we react to variability. While in manufacturing, we, well, manufacture a lot of identical things, in software, each item is different. Thus, on a factory floor, we aim to control and reduce variability, while in software, we tend to accept and work around it.
There are other differences in flavor, too. Like in knowledge work we don't stress too much about waste reduction, while in manufacturing, it's a big theme, etc.
However, if we look at the ideas and not specific implementations, these systems are very similar. And I'm saying it as someone who trained people in that domain both in knowledge work and manufacturing.
Not that any of this helps with confusion in the naming. Even less so given the fact that some people are arguing the seemingly fundamental differences between using kanban (lowercase k) and Kanban (capital K). I guess people are people.I don't much care. As long as someone can explain what they mean by it, I'm fine with whatever naming they come up with.