There has recently been yet another discussion of Kanban on one of the Scrum lists. Kanban has some interesting ideas, and yet it seems to conflict with Scrum in some essential ways. The problem isn't Kanban: it's the notion of "essential ways".

Briefly, Scrum is iterative, and Kanban is not. Scrum specifies that the work is done in time boxed intervals called “Sprints”, and Kanban envisions work as continuous. It is OK to have what Kanban calls a “cadence”, but it is not required.

Scrum has a number of rituals built around the Sprint: it has Sprint Planning, Sprint Review, and Sprint Retrospective. Kanban requires none of these, though I suspect that most Kanban supporters would be in favor at least of reviewing the product from time to time, which corresponds to Sprint Review, and reviewing how things are going from time to time, which corresponds to Sprint Retrospective. They might even favor lifting their heads up and looking into the future a bit to plan what might happen.

(I’m not certain on the Retrospective. Kanban people–continuous flow people in general–often seem to believe that all issues with the process will be sorted out by small changes based on what is seen in the kanban flow. I’m not sure they believe that but often it seems to me that they do. However, Toyota has the notion of “stop the line” and I think this often represents a look at the overall process, analogous to the Sprint Retrospective.)

Many Scrum teams are now using a “story board” or “task board”, showing the work to be done, and what stage each item occupies at the present moment. This is essentially the same board a Kanban team would use. A Kanban team would have Work In Process limits on the board; a Scrum team may or may not do this.

The whole notion of a story board is outside Scrum, and is a bit of a problem. The conventional Scrum approach has been a “Sprint burn down” chart, which is less informative than the story board, and not much easier to maintain. I expect to see the Sprint burn down chart displaced by story boards in most Scrum implementations over time.

It seems, therefore, that there are great similarities between how people use Kanban, and how they use Scrum, but that “they differ in essential ways”.

There are no Essential Ways (but there are things we can't do without.)

It is the thesis of this “Beyond Agile” book that we can’t go beyond Agile without first getting to Agile, and that to get to Agile there are some things that we simply must do. At base, if nothing else, we must focus on the frequent delivery of Running Tested Features.

To be able to measure ourselves by Running Tested Features–by the actual production of actual software–there do seem to be practices that are essential, that we must do. Discussed elsewhere, these include automated tests, cross-functional teams, refactoring, continuous integration, and so on.

These practices, or skills as the Agile Skills Project calls them, seem to vary from optional (perhaps pair programming) to indispensable (perhaps refactoring). Some of them we can get along without, or substitute one for the other, but others seem to be, well, essential.

But they are not “Essential Ways”. They are not dogma or dictated rules. These practices that range from seemingly indispensable to optional are mostly just behaviors that we apply as we need them–and sometimes we seem always to need them.

Often people used to ask “Is it still XP if we don’t pair program?” My answer to this, today, is that this isn’t a very good question. A better question would be “Will we still be effective if we don’t pair program,” and the answer is “You will probably be less effective. How much less depends on what other things you are doing, and how well you’re doing them.”

To me, the notion of Agile software development revolves around measuring ourselves primarily by our actual delivery of valuable software that works, focusing on interactions and collaboration, and demonstrating the ability to change in response to what happens.

Some of the things we need to do to work that way are turning out to be very clear and consistent. Other practices are optional: some may even apply in one circumstance and not another.

But in my opinion, none of the differences such as those between “Scrum” and “Kanban” are essential. They are just choices based on what people like, what they have observed, and how they like to express their ideas.