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.

> So software developers came up with a system that works well for them, but instead of giving it it's own name they reused the name from a manufacturing system. thus leading to endless confusion.

It's amusing to me, because without knowing any of this I've often felt & said that (especially scrum but kanban too) is depressing even just in the terminology used and seems designed to treat us like workers on a factory line. And lo, that is actually whence kanban at least came.

You would think that, but swap manufacturing and parts logistics for user design and content, so a new feature is designed, then content is written for it, then it is implemented. Each step requires the one before it.

My angst with this (IMO tortured) metaphor, is each step is different every time. If we were knocking out exact clones of software systems this would work more like it is expected to.

Management seems to latch on this system since they understand it; it's getting both better and worse in that a lot of management now days has actually written code in smaller companies, but in bigger ones they still bring in their buddies who last coded at Uni and still go hard into this "fungible developer" assembly line process.

I guess within a product this metaphor works better. For example a new page with a new form is likely to be an adaptation of an existing form.

Service ot service this is less appropriate, but extending an existing service is a bit more like assembly line stuff

> but extending an existing service is a bit more like assembly line stuff

(IMO) only if most of the assembly line has to be at least partially retooled every time you do it. No software feature in any but the most basic of systems stands alone.

Which, tbf, a lot of Lean/Kanban software teachings do account for, but most management likes to gloss over.

I can recommend reading “The Phoenix Project”.

Just finished it. So true.