Scrum Is To Kanban As Knife Is To Fork

I have heard several talks and attended several presentations both comparing Scrum and Kanban and explaining how they can be used together.  I came across this article, which talks about this article (I list both because the commenting article brings up good points, too).  So why am I adding yet another level of indirection to this chain?  Because an awful lot of people understand past the surface and the buzzwords of the various flavors of Agile/Lean, and that leads to confusion, unmet expectations, and failed projects.  The most important  point of these articles is that Scrum and Kanban are not interchangeable techniques.  They differ greatly in scope and goal.  That’s why they bring up the metaphor of choosing between a knife and fork.

I hope you read both articles, but here are some of the major points:

  • Scrum is all about time-boxing so deliverable product is produced at a predictable rate, while Kanban is all about controlling flow (I guess you could say workload-boxing) so work doesn’t get backed up at any one stage.  They’re both trying to keep things moving and minimized work in process, but in very different ways.
  • Scrum is an iterative process, while Kanban is a continuous process.   Scrum iterations go through several stages, then you reset the ride.  With Kanban, there are no iterations or natural cycles, just work moving from one step to the next.
  • Scrum is mostly focused on the actual software development process, while Kanban breaks the larger process into smaller steps, and includes things that Scrum doesn’t focus on, like the individual steps in time estimation, release, and deployment.
  • Scrum is more detailed in its process, while Kanban is more general.  Because of this, Kanban may be appropriate for many more situations than Scrum.  For instance, many processes can’t be parsed into iterations, like IT work, sales, customer service, etc.
  • Scrum can be combined with Kanban, by using Kanban inside of Scrum (running each iteration using Kanban).  That might not deliver the full benefits of Kanban, but it can certainly help prevent things like work piling up waiting for QA, or everyone waiting around for the DBAs to do their part.

The last point from these articles is just as important; Using Scrum, or using Kanban, or Agile, or Lean, are not goals.  They are the means to achieve your goals.  Using any of these techniques because they’re hot or someone said you should will rarely lead to a productive team.  First figure out what problems you would like to solve with your development process, establish measurable goals, then pick the techniques you feel will move you towards those goals.  Let the horses pull the cart, not drag it.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.