As organizations come to understand Kanban, they’re increasingly are deciding to use it for some or all of their work. In my experience however it’s pretty easy to do Kanban incorrectly or ineffectively, because there are so few rules to follow. Here are two questions you should be able to answer if you’re really doing Kanban they way you should.

As described in David Stevens’ book on the Kanban system for building software, there are only a few rules to follow:

  1. visualize your workflow
  2. limit your work in progress
  3. make your agreements explicit

As an aside, I strongly encourage teams to include in their agreements an expected service level agreement (SLA) for how long work items in their Kanban will take, perhaps a different SLA for each class of service. But that’s a different post.

Plenty of teams have defined a basic workflow, consisting of only a few steps: a backlog, a selected for development queue (aka input queue), an “in progress” queue, and done. This workflow, while complete and acceptable, is not optimal for Kanban because it doesn’t visually show you your true workflow, just a black box of “in progress”, but again, that’s another post.

If a team has not identified and created a visual workflow, then obviously they’re not doing Kanban at all. Many teams have a visual workflow, but for some reason fail to limit their work in progress, or fail to honor those WIP limits once they are established. Teams that don’t have WIP limits simply aren’t doing Kanban either.

But what about teams that have a workflow identified, that have WIP limits that they observe. How can you tell if they are doing Kanban effectively? Since Kanban is designed to
show you where the bottleneck in your workflow is, and to help you tune your workflow to optimize the delivery of value, there are two simple questions that will help you understand if the team is using Kanban to do this, or simply as a way to track work. The first question is “what was the last change you made to your workflow or WIP limits?” and the second is “what effect did this have on your lead time for work items?” If a team can’t answer these two questions, then they are not looking at their workflow, identifying bottlenecks, and adapting their work accordingly. Teams that aren’t doing this are simply going through the motions of tracking their work, and not improving at all. This misses out on the primary purpose of a Kanban system.


RSS feed | Trackback URI

Comments »

No comments yet.

Name (required)
E-mail (required - never shown publicly)
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.