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.
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.
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.
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-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)
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.