Henrik Kniberg has written a white paper comparing Kanban to Scrum, "Kanban versus Scrum." The connotation of "vs" has had negative side-effects when used on the Kanbandev list so I will avoid it and use the term "compared to" instead.

Mike Bria has posted a response on InfoQ.

While I respect Henrik's work and it has proved to be both popular and useful to folks in the field trying to make decisions about whether to adopt Kanban or Scrum, I find some disagreement with Henrik's assessment that both Scrum and Kanban support "pull scheduling" and "limit WIP."

Kenji Hiranabe and I discussed this point over a year ago before his second Kanban article for InfoQ. I argued and I believe Kenji concurred that Agile methods like Scrum are really small batch transfer push processes. There is no explicit pull system within a Sprint and it's a stretch to suggest that the batch transfer at the beginning of a Sprint - the selection of the backlog - is a truly "pull" process. It is never described this way. It is described as a negotiation where the team estimate a set of stories that the product owner wants done. They compare the estimate with the previously achieved velocity and decide what can be fitted into the available time in the Sprint. If it were truly a pull system then there wouldn't be any negotiation. The product owner would have a prioritized backlog and the team would simply pull the top (however many) stories from it and start work.

We could go further and point out that Kanban doesn't treat the development process as a black box. It is a white box with explicit WIP limits and "pull" happening along the value stream. It's this that makes it a true "pull" system.

So I don't agree that Scrum or other Agile methods based on time-boxed iterations limit WIP. What they do is match small batches of work to limited time periods. They limit time, not WIP. The side effect is smaller batches which is a good thing but it isn't explicit WIP limitation. Meanwhile, they do not truly pull and if we did take the view that Sprint Planning represented pull then at best it is "black box pull" rather than a true "kanban pull."

The comments on Mike Bria's article are particularly worth reading and commenting upon. Adron Hall's comment is for me right on the money...

Scrum still sounds like its for revisionist Waterfall practitioners than Agile"ish" in nature. All of this time boxing, scheduling, planning, and other errata ends in BDUF more often than not. Kanban however, the projects I know of, rarely fall into the BDUF trap and rarely get bogged down or frustrated as many do with Scrum.

Scrum like all early (first generation) Agile methods really do not change the project management paradigm very much. They still use projects as the frame of reference and still have the triple-constraint (iron triangle) of scope-schedule-resources as an underpinning. Agile methods chop the schedule into iterations to mitigate risk and they dispense with the dependency graph tracking paradigm, and take an explicit view on the triple-constraint trade-off - they fix schedule and resources and drop scope if the project is falling behind.

Kanban completely dispenses with the project paradigm altogether. Kanban is based on the paradigm of "flow." The idea that a (development) team forms part of a value stream which pulls work and produces a continuous flow of value. In Kanban we have initiatives attached to value streams and program management that allocates resources across a portfolio of investments. As I explained in my paper for the Lean & Kanban 2009 conference (extracted from Chapter 21 of my forthcoming book) Kanban dispenses with the triple-constraint paradigm and produces a risk optimal outcome based on class of service pull policies that empower a team to self-organize content for delivery that optimizes value while minimizing risk.

Cloves Almeida's comment about Critical Chain misses the point.

Critical Chain Project Management is a "straight to project" implementation of TOC and Lean philosophy. It uses much of lean principles like Kanban, but deliver the concepts more practically.

Many folks in the Theory of Constraints community seem to miss it too. They get caught up in "Critical Chain is the TOC application for Project Management" and forget to question whether the project management paradigm is the right approach. The basis of my work since 2002 has been to see software development as a flow problem and to apply the TOC application for flow problems - Drum-Buffer-Rope (DBR). DBR is another variant of a pull system. It is a close cousin of Kanban. The differences between them are quite esoteric in nature. I make some explanation of why I switched from DBR to Kanban in Chapter 2 of my book. The essence of which is Kanban is easier to say, to explain, to adopt, to understand, and is more graceful in recovering for an outage in the bottleneck resource.

So Cloves is correct that Critical Chain is "straight to project" but my argument has been that this is not useful. In my view Critical Chain is what folks like Alan Barnard of Goldratt Consulting call a "symptomatic fix." It is an improvement on the dependency graph, triple-constraint paradigm of project management. However, the root cause fix is, in my opinion, to change the paradigm. So I disagree with Cloves at quite a fundamental level. I do not believe that Critical Chain delivers the "concepts more practically." I have discarded Critical Chain from my toolbox and never discuss it with clients. I focus on re-orienting them to the flow paradigm instead. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, TOC, Critical+Chain, DBR