I tried to clearly define Kanban as a "Kanban (meaning signboard or billboard) is a scheduling system for lean and just-in-time production. It’s a system to control the logistical chain from a production point of view. Kanban was developed by Taiichi Ohno, at Toyota, to find a system to improve and maintain a high level of production. The Kanban Method was later added to as an approach to incremental, evolutionary process improvement for organizations."

The point is that it is a mistake to take a methodology that was created for incremental process enhancement along a manufacturing line and apply it to software development.

So, I've had the opposite experience: lean-type incremental process enhancement has had dramatic improvements on the end-to-end results of more than one company I've been involved with.

I look at a book like The Phoenix Project, written by some fairly respected software industry folks like Gene Kim, and they also recommend the opposite: that software development and IT operations actually are a lot like an industrial shop floor and benefit from being organized in an end-to-end pull flow like Kanban.

I look at Four Steps to the Epiphany by Steve Blank, or Lean Startup by Eric Ries, while they aren't specifically dictating a Kanban board in their work, they're clearly philosophically in the camp of a pull-based approach to organizing work and limiting work-in-progress.

So, what I haven't determined from your article is, what specifically is flawed with these authors views and my experiences? Am I being over-broad in their inclusion? My interprtation of your article this far is a well-meaning but under-argued philosophical aversion to being lumped in with other industrial engineering practices.

Edit: clarity

From my experience and from what I am hearing it (meaning Kanban) does not work for most folks or companies. That's it. It might work well for you and that's great too. I don't think Kanban and Agile philosophies are the same though - but that's at least another long blog post.

Fair ball. I'd say if its being latched onto as a panacea, almost all approaches to process will fail if you lack the basics: a good market, an insightful product owner/manager, good engineers, and at least an adequate morale in the company.

I've seen companies/projects with all of those things still fail because of a poor process. This is where something like Kanban can help, IMO. Not trivial to implement though.

I don't know much about Kanban as a software development method, but from the description it seems more closely related to the original Kanban concept than the Kanban Method. Kanban (the card system) is mainly about controlling work in progress and not so much about 'incremental process enhancement'. It sounds like the software methodology tries to mainly control the amount of in progress work as well.

This isn't really a criticism on the point your making in the article by the way, which I think is still valid. I find it weird too that software development is being shoehorned into a manufacturing job control system.

Totally agree. That's what was shocking to me as well when I started to drill into it after hearing so many folks complain about it. I think it is a sign of engineering managers struggling to find a simple process to deliver product more predictably. Unfortunately, it seems to be doing more harm than good.

Have you read any of David Anderson's book? Are you aware that the Kanban Method is an adaption of Taiichi Ohno and W. Edward Demings guidance in lean manufacturing to the knowledge work domain? The Kanban Method is specifically designed for knowledge work organizations, which also includes software development activities.