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…
4 thoughts on “Response to critical article on Kanban”
You really put your back into this post. Very impressive.
I find it odd that timeboxing has become central to this argument about how great agile was, when timeboxing wasn’t even an original feature of agile. It’s an afterthought.
Thanks for this.
good arguments. good discussion. I’m still not convinced, but thanks very much for taking me seriously.
You should read these, though:
@Chris I believe that like you wrote in your post, many more think the same way but don’t have the guts or the inclination to express their views. Thanks for expressing your views in your blog. It is from discussion (controversy even) that light comes and that makes all smarter! 🙂 So, thanks for your post.
Regarding the Michael Bolton post you link to: I’ve read it and read it already when Timothy Fitz first published his post.
I see Michael’s point but I also believe that he fails to see the completely different paradigm that can come after you are able to release 50 times a day. I do respect Michael and his professional knowledge/experience, but he is missing the main point. If you can release 50 times a day every bug can be fixed “now”, instead of “later”. This, in the log run, leads to higher quality software.
As Jim Benson points out, time-boxed iterations are not part of The Agile Manifesto. Strange the threatened Agilists would resort to them as a defense.
Comments are closed.