4 ms·

People like to forget a thing: Kanban, which is the scrum "ancestor", was designed for FACTORY MASS PRODUCTION of already designed parts, not for designing new

by kkfx 2y ago

People like to forget a thing: Kanban, which is the scrum "ancestor", was designed for FACTORY MASS PRODUCTION of already designed parts, not for designing new ones, on other words it's a system that works only if what you do is pre-defined, does not demand much intellectual, creative activities and anything it's well known in advance. Applying it to creative activities is a classic application of a religion to a society blindly believing it's universal. It's not. That's the substantial stress.

oneshtein 2y ago
Continuous delivery IS mass production.
- senko 2y ago
  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.
  - oneshtein 2y ago
    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.
    - senko 2y ago
      > 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.
marcosdumay 2y ago
Well, it's worth pointing out that the only thing factory kanban has in common with software development kanban is the existence of some artifact called "kanban". What was probably a publicity stunt to use the hype of the other kind, kinda like Java and JavaScript.

by kkfx 2y ago

oneshtein 2y ago

Continuous delivery IS mass production.

senko 2y ago
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.
- oneshtein 2y ago
  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.
  - senko 2y ago
    > 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.

marcosdumay 2y ago

Well, it's worth pointing out that the only thing factory kanban has in common with software development kanban is the existence of some artifact called "kanban". What was probably a publicity stunt to use the hype of the other kind, kinda like Java and JavaScript.