3 ms·

This is where I see the trouble when How is limited to engineering! (As an e.g. https://news.ycombinator.com/item?id=6119340 https://news.ycombinator.com/item?i

This is where I see the trouble when How is limited to engineering! (As an e.g. https://news.ycombinator.com/item?id=6119340 https://news.ycombinator.com/item?id=6119340) You need to be able to capture every activity and every team that gets involved in the process. If not you will have a dysfunctional company where each department does not see the whole picture of how we push features. How = PM setting out the stories, Marketing putting down the value (how else are you going to sort the que?), Engineering building it, IT managing it, PM measuring the usage, and capturing the actual value denoted by the customer. The board should be able to capture all these. In turn providing feedback to every team. For e.g. if Marketing is constantly assigning wrong values to features, then we need to figure out what do we need to do put in right estimates for them? etc ... Kanban is about looking at the whole picture by breaking it down into the actual activities you as a team are involved in. You could be actually following a waterfall process internally but still observe it, capture it, measure it and then improve upon it. That's when its a kanban process. Everything else is cargo culting.

bdehaaff 13y ago
I think that is your more advanced product development system. I don't that is the definition of Kanban or what it was devised for. It reminds me of Agile -- everyone is now Agile but no one describes it the same way. Thanks for your feedback.
- parasubvert 13y ago
  I think that actually is exactly what Kanban was devised for and largely the context of the David Anderson quote in your article: Kanban is not for software development, it is a technique for seeing, organizing, and improving the end-to-end process of how an organization accomplishes stuff. It is not a complete software process: it says nothing about QA/testing for example. Nor is it a complete marketing process: it doesn't say anything about how you determine market values. It's about making all these sub-processes flow together, and identifying where the bottlenecks are. There's a presentation from DJA on where Kanban is not appropriate here: http://www.slideshare.net/AGILEMinds/david-anderson-kanban-when-is-it-not-appropriate http://www.slideshare.net/AGILEMinds/david-anderson-kanban-w... Not an easy read. That said, it aligns to what you've been saying in your article (I think): the WHAT and WHY is irrelevant to Kanban, it can't help you there. The HOW, sure: but even there it is more of an overlay on existing process, not a catch all "one method to rule them all". Where we get into trouble is that I think your article is saying "Kanban doesn't work, do this process instead". But the process you sketch out probably would fail too in many organizations that lack a good handle on what they're doing and why. Any process will, even goal-driven ones (which IME tend to work only in small scales with few cross-department interactions)
parasubvert 13y ago
Agree, though in fairness I've found it's necessary to get away with "black boxing" certain non- cooperative groups in the short run, and treating them as a fixed constraint.

bdehaaff 13y ago

I think that is your more advanced product development system. I don't that is the definition of Kanban or what it was devised for. It reminds me of Agile -- everyone is now Agile but no one describes it the same way. Thanks for your feedback.

parasubvert 13y ago
I think that actually is exactly what Kanban was devised for and largely the context of the David Anderson quote in your article: Kanban is not for software development, it is a technique for seeing, organizing, and improving the end-to-end process of how an organization accomplishes stuff. It is not a complete software process: it says nothing about QA/testing for example. Nor is it a complete marketing process: it doesn't say anything about how you determine market values. It's about making all these sub-processes flow together, and identifying where the bottlenecks are. There's a presentation from DJA on where Kanban is not appropriate here: http://www.slideshare.net/AGILEMinds/david-anderson-kanban-when-is-it-not-appropriate http://www.slideshare.net/AGILEMinds/david-anderson-kanban-w... Not an easy read. That said, it aligns to what you've been saying in your article (I think): the WHAT and WHY is irrelevant to Kanban, it can't help you there. The HOW, sure: but even there it is more of an overlay on existing process, not a catch all "one method to rule them all". Where we get into trouble is that I think your article is saying "Kanban doesn't work, do this process instead". But the process you sketch out probably would fail too in many organizations that lack a good handle on what they're doing and why. Any process will, even goal-driven ones (which IME tend to work only in small scales with few cross-department interactions)

parasubvert 13y ago

Agree, though in fairness I've found it's necessary to get away with "black boxing" certain non- cooperative groups in the short run, and treating them as a fixed constraint.