3 ms·

Isn't that the role of PM, and management? That's what they are for. To ensure that people do not lose sight of the bigger picture. When you first implement a

Isn't that the role of PM, and management? That's what they are for. To ensure that people do not lose sight of the bigger picture. When you first implement a process, any process (waterfall, kanban, scrum, whatchamighticallit) the first cycle is going to be hard as everyone is trying to adjust to the new way of doing it. Some people will buy in, some people will call it a fad, some people will like to wait and watch. So first time around you are going to see these issues, but then the question to ask is, are you measuring the activities? Are you looking at the metrics? Are you debugging the process by trying to ask questions on what the metrics are telling you? If not any process will fail. And in case of Kanban, metrics are the most important data to understand your cadence. How else will you identify waste, identify bottlenecks and also get into "continuous improvement". To me goal of any good process should be: a) Provide feedback as early as possible on every activity thus improving the possibility of success. b) Reduce the cost of transaction in some form by either improving productivity or reducing waste. c) Build a team which works as a collective whole with everyone aware of what needs to be get done and when and for what purpose. If any process fails to do these, you have a failed process.

bdehaaff 13y ago
Fair enough. I think there is they Why (strategy) the What (features and user stories) and the How (engineering getting bits out the door). I am poking at when the How overshadows the Why and What. That's when things go sideways.
- bhattisatish 13y ago
  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

Fair enough. I think there is they Why (strategy) the What (features and user stories) and the How (engineering getting bits out the door). I am poking at when the How overshadows the Why and What. That's when things go sideways.

bhattisatish 13y ago
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.