1. You were horribly misled in your early efforts to value stream map your process flow as activities over states, and I get that frustration. There was a reason early Scrum walls were just three columns: To Do, Doing, Done. Kanban promised to more closely model how the work is done and set the stage for misunderstanding.
2. There is rework in physical plant operations where product from later stages gets kicked back to prior ones introducing delays and increased costs.
3. Taiichi Ohno said something that always stuck with me about kanban, though from the original manufacturing context: the purpose of the kanban is to eliminate the kanban. In other words as a tool to take you from where you are to a new state, not becoming encased in amber.
A lot of lean folks miss this too, and go all-in on tools rather than evolving their system as Ohno did for Toyota over decades...
Let me respond to each of your thoughts individually:
1. Fair. A Kanban Board, when read as sequence of actions, may be misleading. Yet, this is re-stating the point. The Kanban Maturity Model's starting point is exactly such a Scrum-Board as you describe. And "Doing" is a state, a space where whatever action(s) in whatever order that makes sense to get the work to the "Done" state, is applied. This works reasonably well in Scrum's 1-4 week timebox, because splitting "Doing" into more granular states adds little value. Well, one could argue about the upper end - especially since AI has happened to us. But let's put that aside. If "Doing" gets longer though, the desire to get a more granular insight into what's going on is understandable. And splitting the "Doing" state (!) into multiple ones is exactly the right means if more insight is needed to improve flow. Just avoid to prescribe a sequence-of-actions - and don't overdo it.
2. The kickback is a result of the immobility of production machinery in manufacturing. It is a unavoidable disturbance of the flow there. Remove that physical constraint (and in creative knowledge work it is removed), and moving the workers downstream becomes the right move. And to my knowledge, that's exactly what used to happen first when the Andon-Cord was pulled: The line stopped and upstream workers moved downstream to see what the issue is.
3. It's a bit unclear - at least to me - which "the Kanban" Ohno referred to here. If it is the one used to signal/manage replenishment of material, then of course it is, because that replenishment still is a (small) batch and hence waste (NVA inventory). In Kanban for creative Knowledge work, the Signal/Kanban is something else entirely. The Signal is not the Card or Ticket in some work-management software that travels downstream. It's the free slot in a WIP-limited state that signals free capacity and travels in the opposite direction. And that signal never vanishes or should be eliminated, even in the purely theoretical optimum of Single-Piece-Flow.
Of course I fully agree that going all-in on tools instead of understanding is questionable.
The intent wasn’t to suggest a Scrum Board as the end-state. It evolves over time. An anti-pattern common to both Scrum and Kanban is the tendency (although not always) to crystallize the board and adapt the work to fit. When I consulted/coached teams on both systems, I would remind them if they’re doing Scrum or Kanban the same way on day 120 as day zero, they need to look at whether they’re learning about the work and how it is done and make sensible changes accordingly.
The kickback isn’t a matter of “immobility of production machinery” as much as inattention to QUALITY. Both physical and knowledge work products are focused on how well they can meet the needs and requirements of an end-user. There is variation in both types of products, which is the product of multiple interactions that take place over time. There is not as much difference here as you’d think. The Andon Cord was Toyota’s response to preventing escaped defects - we have the same thing in software development where we run automated regression and integration tests to make sure we don’t break the build.
Kanban to Ohno was the replenishment card — he was concerned with keeping the flow of material to production, so this was vital, but he knew it was a stepping stone to enable other refinements and discoveries in the process. Similarly, Kanban for software/knowledge work isn’t about the board, it’s about learning the nature of the work and how it can be improved. The whole point of regular retrospectives isn’t to refine the board, but to get to a higher state of working, and that is VERY HARD in most places because teams and their organizations don’t last long enough to do this kind of deep learning.
Some thoughts:
1. You were horribly misled in your early efforts to value stream map your process flow as activities over states, and I get that frustration. There was a reason early Scrum walls were just three columns: To Do, Doing, Done. Kanban promised to more closely model how the work is done and set the stage for misunderstanding.
2. There is rework in physical plant operations where product from later stages gets kicked back to prior ones introducing delays and increased costs.
3. Taiichi Ohno said something that always stuck with me about kanban, though from the original manufacturing context: the purpose of the kanban is to eliminate the kanban. In other words as a tool to take you from where you are to a new state, not becoming encased in amber.
A lot of lean folks miss this too, and go all-in on tools rather than evolving their system as Ohno did for Toyota over decades...
Let me respond to each of your thoughts individually:
1. Fair. A Kanban Board, when read as sequence of actions, may be misleading. Yet, this is re-stating the point. The Kanban Maturity Model's starting point is exactly such a Scrum-Board as you describe. And "Doing" is a state, a space where whatever action(s) in whatever order that makes sense to get the work to the "Done" state, is applied. This works reasonably well in Scrum's 1-4 week timebox, because splitting "Doing" into more granular states adds little value. Well, one could argue about the upper end - especially since AI has happened to us. But let's put that aside. If "Doing" gets longer though, the desire to get a more granular insight into what's going on is understandable. And splitting the "Doing" state (!) into multiple ones is exactly the right means if more insight is needed to improve flow. Just avoid to prescribe a sequence-of-actions - and don't overdo it.
2. The kickback is a result of the immobility of production machinery in manufacturing. It is a unavoidable disturbance of the flow there. Remove that physical constraint (and in creative knowledge work it is removed), and moving the workers downstream becomes the right move. And to my knowledge, that's exactly what used to happen first when the Andon-Cord was pulled: The line stopped and upstream workers moved downstream to see what the issue is.
3. It's a bit unclear - at least to me - which "the Kanban" Ohno referred to here. If it is the one used to signal/manage replenishment of material, then of course it is, because that replenishment still is a (small) batch and hence waste (NVA inventory). In Kanban for creative Knowledge work, the Signal/Kanban is something else entirely. The Signal is not the Card or Ticket in some work-management software that travels downstream. It's the free slot in a WIP-limited state that signals free capacity and travels in the opposite direction. And that signal never vanishes or should be eliminated, even in the purely theoretical optimum of Single-Piece-Flow.
Of course I fully agree that going all-in on tools instead of understanding is questionable.
The intent wasn’t to suggest a Scrum Board as the end-state. It evolves over time. An anti-pattern common to both Scrum and Kanban is the tendency (although not always) to crystallize the board and adapt the work to fit. When I consulted/coached teams on both systems, I would remind them if they’re doing Scrum or Kanban the same way on day 120 as day zero, they need to look at whether they’re learning about the work and how it is done and make sensible changes accordingly.
The kickback isn’t a matter of “immobility of production machinery” as much as inattention to QUALITY. Both physical and knowledge work products are focused on how well they can meet the needs and requirements of an end-user. There is variation in both types of products, which is the product of multiple interactions that take place over time. There is not as much difference here as you’d think. The Andon Cord was Toyota’s response to preventing escaped defects - we have the same thing in software development where we run automated regression and integration tests to make sure we don’t break the build.
Kanban to Ohno was the replenishment card — he was concerned with keeping the flow of material to production, so this was vital, but he knew it was a stepping stone to enable other refinements and discoveries in the process. Similarly, Kanban for software/knowledge work isn’t about the board, it’s about learning the nature of the work and how it can be improved. The whole point of regular retrospectives isn’t to refine the board, but to get to a higher state of working, and that is VERY HARD in most places because teams and their organizations don’t last long enough to do this kind of deep learning.