Agile Zone is brought to you in partnership with:

Mitch Pronschinske is a Senior Content Analyst at DZone. That means he writes and searches for the finest developer content in the land so that you don't have to. He often eats peanut butter and bananas, likes to make his own ringtones, enjoys card and board games, and is married to an underwear model. Mitch is a DZone Zone Leader and has posted 2573 posts at DZone. You can read more from them at their website. View Full User Profile

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

01.18.2010
| 19420 views |
  • submit to reddit
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".

Comments

Philip Crawford replied on Mon, 2010/01/18 - 3:31pm

I like this quote:

Building a sandcastle for fun, Kniberg says, is a process that doesn't need to be controlled.

Control is the key word in this sentence.  Kanban helps people think they have and need "control" of a process.  It is almost inherently not agile in nature.

If I'm working with a few developers on a small startup (which I've done numerous times), there is no need for Kanban.  We deploy code continually with virtually no WIP.  Kanban would be a silly notion for such a small group. We need to be agile. 

For larger organizations where WIP becomes an issue, sure, use kanban.  But don't confuse lean processes from being agile, they are two different animals.

 In case you are wondering, I've implemented kanban several times during my professional career.

Armond Mehrabian replied on Fri, 2010/01/22 - 12:14am

Henrik is fantastic at simplifying seemingly complex topics. He's done a great job at explaining Kanban to the masses. I think he's spot on when he states that Scrum does not work well in maintenance or sustained engineering situations.

I'm not sure I follow his "kanbanizing" Scrum concept.

-Armond Mehrabian

Twitter: @armond_m

Tech Fun replied on Tue, 2012/10/02 - 11:21am

Well, scrum is not better than waterfall, it's just smaller.

 

Smaller matters. Facilitied with continous delivery, Kanban is better on delivery time and feedback loop.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.