Response to critical article on Kanban

I was reading Chris McMahon's post "Against Kanban" and could not help but think that a response was in order. The post below is a response, in detail to the (flawed) arguments that Chris makes against Kanban.

"were revolutionary, because they were software development processes actually created from scratch by people who were very very good at creating software."

In here, however you forget that Mike Beedle and Ken Schwaber explicitly mention the chemical industry as a source of learning when putting together the explanation for the success of Scrum.
You further forget that Jeff Sutherland (and others) have often referred to Takeuchi's and Nonaka's paper (The New New product development game) that is straight from, you guessed it: manufacturing!

"if your team measures velocity and uses velocity to plan iterations, and if your team always does pair programming, test-driven development, and continuous integration, then you will either release excellent software every iteration; or you will quickly expose and face the reasons why not."

In this phrase you seem to imply that one cannot use the same XP practices with Kanban. Here again you are wrong. All of the practices that make Scrum "work" can be used to make Kanban "work".

"Before we started releasing every iteration, my team had been using a kanban-like process."

This argument is disingenuous. You should have said that you did not have timeboxed iterations. Kanban is much more than not having timeboxed iterations and you fail your readers when you associate a previously used process (not working by your own admission) with something you quite clearly do not fully grasp. A bit like what you blame on your so called "kanban expert".

"Furthermore, it was an enormous headache for the marketing people. Without timeboxes or estimates, it was difficult to know when a particular feature would be available, which made it almost impossible to do effective marketing for the product."

If you had any experience with Kanban or indeed if you knew more about Lean you would know that this phrase does not make any sense in the Lean context. In a (properly working) Lean process you always know when you are going to ship something, that's why Lean is being adopted in the first place. The fact taht you state lack of predictability as a problem inherent to Kanban just means that you don't understand it -- which is fair, but in that case you should not write condemning articles, you should first prove your Hypothesis (BTW: the Hypothsis-Test-Theory cycle, aka PDCA, is at the heart of Lean. Just google for "a3 report problem solving")

"The fundamental difference between software development and manufacturing or engineering is that in software development we do not manipulate physical objects."

This is an obvious truth, but you don't explain the consequences of this phrase. The (other) fact is that manufacturing, like other industries, are very process oriented and processes from all industries have similar theoretical frameworks! Therefore what you learn from processes in the chemical industry (to use Beedle and Schwaber's example) can be used in the software industry!

"I'm sympathetic to those who see estimation and iteration planning as waste, but I think the risk inherent in not having a mechanism to expose our inadequacies is too much risk to take, even for the best of teams."

In this phrase you make an implicit sylogism by which not having estimation and iteration planning leads to not being able to see what is wrong. This is clearly due to your lack of understanding of how a "flow" process can work. In a flow-like process (e.g. Kanba) you don't just retrospect at the end of the iteration (there's none), you retrospect much more frequently, even sometimes a day. This is indeed a much more powerful way to expose "inadequacies" as any tester knows.

"can you deliver running tested features on a consistent schedule? Iteration timeboxing exposes that metric in the most obvious way possible."

I agree that timeboxing exposes the features delivered/iteration metric. Heck, I've been using that metric myself to explain why you don't actually need to estimate (one of the basic problems in Kanban according to you). The point is that the metric you say is impossible to gather with Kanban is the very metric that makes Kanban transparent to the business owners (the cycle time, or how long does it take to deliver 1 feature). You seem to have missed this point also.

"What we find in both literature and anecdote about the application of processes taken from manufacturing and engineering, puzzlingly, is that for every team for which the process is successful and helpful, there are other teams who implement the same process only to meet with failure.

What I suspect is that ANY process or methodology (that is not actively destructive), applied to a skilled, disciplined, high-functioning, motivated team, will succeed, regardless of the process. Likewise, any process applied to a low-functioning team will likely fail."

I agree with these two paragraphs, but the same is true (like you say) for ANY process, even those that did not originate from the manufacturing industry. At this point your post is contradicting itself...

"With an XP/Scrum sort of iterative process, we will know very soon exactly how and why we are failing. This seems to be not true of kanban or of any other software development process taken from the manufacturing arena."

Having read the other comments above you know how false this statement is. The point is that in Kanban restrospectives are part of everyday work (when it is working), therefore you actually find out "how and why we are failing" much faster than in a timeboxed iteration-based process!

Maybe you should also take a look at this post: http://bit.ly/7NhAg in it the author claims (and I can't verify it) that they release software 50 times a day. If you get to that point, what's the reason to have iterations. By your own metric (features released/iteration) this team is already over achieving to the point of making the metric useless...