4 ms·

I am a fan of Kanban, so whatever I say will be through the rose tinted glasses of a fan. There maybe various reasons why Kanban has failed for many companies.

I am a fan of Kanban, so whatever I say will be through the rose tinted glasses of a fan. There maybe various reasons why Kanban has failed for many companies. I haven't worked in those teams so I have no way to say is it because of Kanban or is it because of management misunderstanding kanban. From your article, the main reason touted is that the Marketing loses it's way. Which to me sounds strange! In fact I have seen it the otherways. We effectively delink marketing cadence from engineering cadence! Thus resulting in derisking the whole big bang releases. For e.g. Marketing decides that they are going to make a big marketing push on a conference or a tradeshow. So the PM come up with a list of features they will showcase for the given event. (say 10 features are decided upon). The engineering team works on these features as a que. Releasing each of these as and when they are done. But do note an engineering release to production does not mean a marketing release. This allows the PM to experiment on features, build up case studies, etc ... for these features. And as the marketing releases dates come closer, everybody knows that we always have a working copy with only the pending items in the que. This results in a high confidence level within the marketing / engineering on what is being touted about. There are no last minute scramble to get a working system. etc ... The most valuable feature was heavily tested and used by everyone before the big bang marketing release. It also allows the PM to make A/B experiments before the actual marketing push. Thus adding another confidence layer to the whole process. In a worst case scenario the least valuable features never get released for the marketing push. I see this as an effective way to derisk the whole marketing push and reduce their dependency on the engineering team to deliver stuff when they said they would.

bdehaaff 13y ago
I think that we would actually agree. I don't really care how Eng gets to a major milestone and delivers a good portion of the required features. The issue is that when the teams lose focus of the bigger picture and stop thinking about key dates and what collection of features are needed to win. When any dev methodology becomes the goal and not the means to an end -- companies and their customers suffer.
- bhattisatish 13y ago
  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.
snorkel 13y ago
Unfortunately not all of us are blessed to work with well organized stakeholders who are able to plan ahead rather than wait until the last minute to request whatever they need from engineering. Agile only works when the entire organization abides by its rules, sure engineering teams can train their stakeholders to some degree but upper management can just overule the process and insist engineering should be like a service desk that responds to whatever is needed today. Sucks, but it's a reality in many workplaces.
- bdehaaff 13y ago
  So what methodology have you found that works well in that environment? I am curious what helps you manage the madness as best you can when PM is not organized and "management" meddles.
- bhattisatish 13y ago
  I agree. That's the reason I love Kanban. It allows us to capture metrics on what is being done, how long it took and where are we spending most of our time. This numbers in turn allow us to push the story to management on what they are doing wrong. For e.g. We worked on a team where Sales made a feature request (1 day, PM and design team worked on it and released it to engineering (5 weeks) and engineering released it to sandbox (2 weeks), qa tested it and released it to production (1 week). Guess where the bottleneck is? The whole cadence for the feature was 8 weeks. Obviously Sales where jumping on us for not getting it done on time. This way of looking at the whole board, allowed us to identify a bottleneck and push for changes on how the whole company operates. If you kanban a board only for engineering then you lose the big picture, How is the system as a whole operating.

bdehaaff 13y ago

I think that we would actually agree. I don't really care how Eng gets to a major milestone and delivers a good portion of the required features. The issue is that when the teams lose focus of the bigger picture and stop thinking about key dates and what collection of features are needed to win. When any dev methodology becomes the goal and not the means to an end -- companies and their customers suffer.

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

snorkel 13y ago

Unfortunately not all of us are blessed to work with well organized stakeholders who are able to plan ahead rather than wait until the last minute to request whatever they need from engineering. Agile only works when the entire organization abides by its rules, sure engineering teams can train their stakeholders to some degree but upper management can just overule the process and insist engineering should be like a service desk that responds to whatever is needed today. Sucks, but it's a reality in many workplaces.

bdehaaff 13y ago
So what methodology have you found that works well in that environment? I am curious what helps you manage the madness as best you can when PM is not organized and "management" meddles.
bhattisatish 13y ago
I agree. That's the reason I love Kanban. It allows us to capture metrics on what is being done, how long it took and where are we spending most of our time. This numbers in turn allow us to push the story to management on what they are doing wrong. For e.g. We worked on a team where Sales made a feature request (1 day, PM and design team worked on it and released it to engineering (5 weeks) and engineering released it to sandbox (2 weeks), qa tested it and released it to production (1 week). Guess where the bottleneck is? The whole cadence for the feature was 8 weeks. Obviously Sales where jumping on us for not getting it done on time. This way of looking at the whole board, allowed us to identify a bottleneck and push for changes on how the whole company operates. If you kanban a board only for engineering then you lose the big picture, How is the system as a whole operating.