Kanban – The Secret Engineer Killer

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

As others have noted the definition of kanban comes too late in your article. Also, I think a citation to wikipedia is in order if you're going to copy it and simply expand the initialisms.

Regardless, it's not a particularly helpful definition for anybody that's never heard of kanban, and certainly doesn't help anybody familiar with kanban to know what specifically you're evaluating; you need to get everybody on the same page from the outset.

Given lack of concrete examples and your previous posting history I would consider this more of an advertisement for your product, to which I've now applied for an invitation, but you seem to be genuinely responding to comments here and nobody else has complained. I suppose either way, well played.

I have other comments but I'll hold them until I find out exactly what you mean by kanban, because I've been admittedly self-identifying the process I'm using as kanban and maybe it's not.

I will say this much though, the practices of kanban (visualization, limited work-in-progress, managed flow, feedback loops, etc.) are all valuable in my opinion and I wonder which of these you see leading to, or how you see them leading to, the problems you've cited. Also, I wouldn't mind some more concrete metrics to back up such an inflammatory title.

Fad diets don't work because they are ineffective, not because people go off them. Frankly, if you always followed fad diets, you'd end up killing yourself. Your logic is flawed.

If you just read the subtitles, I'd almost think your article was a piece in favor of Kanban.

Engineers aren't assembly workers: so why do other methodologies seem to be so prescriptive on what can be accomplished in a given time frame? New problems arise, priorities shift, and unexpected news arrives. I appreciate the flexibility of a pull-type system because it lets me transparently show what I'm working on.

I've really hated telling people no or watching a manager struggle to change up something we really need just because it doesn't fit in the right shape time box or might affect the current sprint's plans.

You can't trust yourself: I always ended up hating sprint planning meetings where "points" are a constant source of conflict between stakeholders and estimates are fantastical. These sort of meetings just allow the quality knob to turn down while scope and schedule remain fixed. Having an entire team minimizes estimates problems, but for the effort involved I'm not sure the gains are worth it.

Also, I think you may have inadvertently taken Anderson's quote out of context as well—Kanban isn't a way to run software. It's merely a way to expose your current process so you can improve it. Kanban is something that sits on top and allows you to identify bottlenecks, be realistic about results (instead of estimates) and provide immediate transparency into what you're working on. It doesn't specifically prescribe what the steps are.

I should say I totally agree with one sentiment from the original post: don't blindly pick up Kanban as a magical solution for your problems!

If your underlying process (or lack of process) sucks, then you'll still be in trouble. Fix your process first.