If a factory is producing N widgets, every widget is the same. If a software teams are producing deliverables, each is different.

Kanban (originally) is an method of sending purchase orders (ie requests to make widgets of specific type in some quantity) from the team(s) who need them to the teams who make them.

In software, quantity is always 1 and while the “widgets” have notionally been designed (specced out in the ticket), they have never been built before, unlike in the factory where every widget at least had a test run before.

That is, Kanban in software development is a cargo cult from Toyota in which an essential difference (time to reconfigure the assembly line for another widget, vs time to design, prototype and test the widget) has been lost.

And it STILL works better than Scrum.

Kanban was invented for Just-In-Time factories, where each product item is customized to meet demand, so fewer things can be predicted in advance, thus making Waterfall unsuitable. Kanban allows to achieve both the flexibility of customization and cost effectiveness of mass production.

In software development, incoming requests are broken down into small manageable tasks, which are familiar enough for developers to estimate reliably. Then this continuous stream of small tickets is executed continuously (Kanban) or in sprints (SCRUM).

For example, request to add feature X can be broken down into «Make UI for feature X» and «Make backend for feature X». If they are still large, they can be broken further, for example «Make a CRUD for feature X.y», «Make a SQL table for X.y with migration script», and so on.

> each product item is customized to meet demand

No, each product run is customized. Products are already known and fixed (they have been built before, with the same specs), the demand is unknown (in advance). There is a subtle difference between this and your “make CRUD for xyz”, where XYZ is always something different (if it wasn’t, we’d just reuse the thing we wrote the last time).

I would encourage everyone to read a book about TPS (The Toyota Way is a good one), and compare/contrast that with Kanban as an agile software methodology.