3 ms·

That's true. The notion of what Kanban is differs between knowledge work (stemming mostly from software development adaptations) and manufacturing. Since my co

by flail 2y ago

That's true. The notion of what Kanban is differs between knowledge work (stemming mostly from software development adaptations) and manufacturing. Since my context is primarily IT I made some simplifications when describing the context. Admittedly, the principles are the same. However, because of the differences in the nature of the work, different areas are stressed. A notable example is how differently "removing waste" is considered between IT and manufacturing. Anyway, yes, whiteboards and sticky notes are staple artifacts of software development/knowledge work context. "Old-school" (since it started decades earlier there) manufacturing is much more creative with designing visual signals. On the other hand, knowledge work typically handles uncertainty and variability of work way better. That stems from a different type of process (more creative, less repeatable) and unique nature of each individual task.

jimnotgym 2y ago
>On the other hand, knowledge work typically handles uncertainty and variability of work way better. I am not sure that is true, they are very different but I wouldn't say one handles it better. One of the factories in involved in builds to order on a short lead time. We produce 2500 machines a day, from a wide range with many configuration options. There are various sub assemblies that have to be built first. On any given day there will be shortages on various components, meaning we can't build what we want. There will be quality issues with materials meaning reworks and changes in process. There will be design up-issues to address material changes, firmware problems, or customer demands. There are 400+ people to coordinate. This is all done whilst still shipping 99.9% within the lead time. We don't know anything for certain about our demand in 10 days time. It seems much more complex and adaptable to me than when I ran a software team
- flail 2y ago
  I failed to explain. In the ideal case, in manufacturing, we repeat the same set of tasks to manufacture identical goods. In software development, we have the same stages (development, code review, testing, etc.), but every task going through the workflow will be different. Depending on how these tasks are defined, the effort, interdependencies, etc., might vary wildly. Both types of work, of course, will have variability related to the complexity of the process. And that variability will be correlated with the size of workflow, people and/or machines involved, etc. It's just the knowledge work adds another dimension. By the way, that's why, in knowledge work, we rather talk about accepting variability instead of controlling it (which was the focus in Lean Manufacturing). I recommend Don Reinertsen's work on that, since he worked in both contexts. While his book (Principles of Product Development Flow) is not an easy read, it's absolute gold.

by flail 2y ago

jimnotgym 2y ago

>On the other hand, knowledge work typically handles uncertainty and variability of work way better. I am not sure that is true, they are very different but I wouldn't say one handles it better. One of the factories in involved in builds to order on a short lead time. We produce 2500 machines a day, from a wide range with many configuration options. There are various sub assemblies that have to be built first. On any given day there will be shortages on various components, meaning we can't build what we want. There will be quality issues with materials meaning reworks and changes in process. There will be design up-issues to address material changes, firmware problems, or customer demands. There are 400+ people to coordinate. This is all done whilst still shipping 99.9% within the lead time. We don't know anything for certain about our demand in 10 days time. It seems much more complex and adaptable to me than when I ran a software team

flail 2y ago
I failed to explain. In the ideal case, in manufacturing, we repeat the same set of tasks to manufacture identical goods. In software development, we have the same stages (development, code review, testing, etc.), but every task going through the workflow will be different. Depending on how these tasks are defined, the effort, interdependencies, etc., might vary wildly. Both types of work, of course, will have variability related to the complexity of the process. And that variability will be correlated with the size of workflow, people and/or machines involved, etc. It's just the knowledge work adds another dimension. By the way, that's why, in knowledge work, we rather talk about accepting variability instead of controlling it (which was the focus in Lean Manufacturing). I recommend Don Reinertsen's work on that, since he worked in both contexts. While his book (Principles of Product Development Flow) is not an easy read, it's absolute gold.