Kanban's Not Better than Scrum, It's Just Smaller

henrik kniberg, an agile & lean coach at crisp , has written some great blog posts that compare scrum and kanban.  he says it's unfortunate that most discussions comparing scrum to kanban are focused on trying to see which is better.  "to me, this is rather meaningless," said kniberg.  he renamed a post that was originally titled "scrum vs. kanban" for this reason; people didn't get that it was a joke.  dzone spoke with kniberg about the differences in scrum and kanban.  he also talked about why it's so hard to find inherent problems in kanban.  he thinks that eventually we'll find problems with kanban too.

kniberg uses a fork and knife metaphor to describe the scrum-kanban comparison: "which is better?  a fork or a knife?  most people would agree that's a meaningless question."  the same goes for kanban and scrum.  they cover different aspects of workflow agility, and there's no method that covers everything, kniberg says.  if people believe there is a method that can do everything, he says they need to throw away that belief first.  "that thinking is what's leading us to very heavyweight methods," said kniberg.  scrum, for example, is seen as a cure-all by some organizations, but scrum, like any methodology, has limitations.  scrum only works in a context where iterations make sense.  kniberg says you might have an operations team or a maintenance team that doesn't need to batch work into timeboxed iterations.  scrum could still help those teams, but you wouldn't want to include timeboxed iterations.

the same example doesn't apply to kanban because it's smaller, and more generic.  "in general, i think it's harder to find cases where kanban doesn't work than it is to find cases where scrum doesn't work," kniberg said.  there's a direct correlation, he says, between  how big the process is and how widely it can be implemented.  the bigger the process, the less situations it can work with.  being more generic means that kanban can be applied to more situations, and it seems to fit with almost any context.  "it used to be like that in scrum," said kniberg.  "i was kind of part of the problem because when i first started using scrum, it worked very well in comparison to everything else and it was hard to imagine cases where it wouldn't work well.  now that we've gone past that initial honeymoon period with scrum, it's quite clear where it doesn't work well and i think that's going to happen with kanban too."  right now, kniberg says kanban is working explicitly well in cases where other methods have failed.  however, he thinks that as adoption becomes more widespread, we'll start finding cases where it doesn't work so well.

"i've thought about it, and it would be useful to come up with a case where kanban didn't work, and i can only think of one example so far which is pretty silly: when my six year old son and i are building a sandcastle and having a lot of fun: if someone were to come by and say, 'hey guys, you should use kanban and put up a whiteboard,' we would say, 'get out of here!  we're building a sandcastle!'"  building a sandcastle for fun, kniberg says, is a process that doesn't need to be controlled.

he says ideas like visualization of work and limiting work in progress are intuitive ideas that are hard to find fault with.  kniberg said organizations have sometimes misused kanban by creating the illusion of predictability in situations where the process isn't repeatable.  "i've seen some tendencies with cross-functional scrum teams where they fall into the trap of starting to use kanban within the sprints.  so they set up this false workflow (analysis, code, test, etc.) and what they've done is they've imposed a structure and a predictable, repeatable workflow which wasn't there in the beginning, and that limits them by taking away the whole advantage of being cross-functional."  kniberg says that in most of those cases, however, the team will end up fixing the board because it feels intuitively wrong.  "these kinds of mistakes are really just part of the learning curve," he said.

if used correctly, kanban, scrum, and other methods can work together effectively.  kniberg said that using kanban to map what is happening around the scrum team is the combination that is most likely to succeed immediately .  "the scrum team's whole work might be a single column on the kanban board,"  said kniberg.  "you use the kanban board to show what wasn't there before, in other words, what happens before the sprint and what happens after.  in that case, there's nothing you can lose by using kanban."  kniberg has come up with his own word for making the scrum sprint part of a higher level kanban workflow.  he calls it "kanbanizing" of a scrum team.

if you want to learn more how scrum and kanban relate take a look at henrik's new book "kanban and scrum - making the most of both".