How is the Kanban board different then a normal Agile board?

In comments on my recent post, What’s Deming Go To Do With Agile, I proposed that Kanban brings an easy to implement – low friction implementation of Deming’s philosophy. Daryl Kulak disagreed – it turns out that this was based on the presumption that implementing Kanban included a prescribed implementation of TPS, TQM, and other Lean tools. We sorted it out and then Daryl made an excellent point – a normal Agile board can be used to learn from the system in the same fashion the Kanban board can. I believe this is true. In fact, I believe that the Agile board and the conversations and ceremonies around it are key to the success of Scrum teams. So, how is the Kanban board approach different then a normal Agile board approach?

No Role Changes Involved

Whether you are currently doing Agile or not, putting up a Kanban board to visualize your system requires no other changes. At the onset you don’t change any roles, ceremonies, artifacts, or measurements. You do need to go through the effort of defining the board collaboratively – involving performers, management, customers, and suppliers.

Just start with what you have. Establish a system boundary for your board. Identify the states your work goes through inside the boundary (i.e., Analyze, Develop, Accept, Release) – especially reflecting hand-offs or a shift in approach (i.e. talking about it, unit testing and coding, starting acceptance test, preparing for release). Put these states as columns on the board. Then define the various work item types that go through your system. Write up all the Work in Process on cards and place them on your board.

Use the board to understand what you have and think about it. As Daryl points out, Deming says “study your system THEN find tools to fix the problems you see.” This board will create an opportunity to create a shared understanding of your system among all the stakeholders. That’s it. In about a day you can have your board defined and within a week you will have your work moving across the board.This may not seem powerful, but in my experience this effort is extremely valuable. I have seen productivity dramatically increase just from this exercise – no role changes, no engineering changes, no changes in how we do requirements. Just making the work in the system visual and talking about it once a day.

A Broader View of the Value Stream

A normal Agile board is focused on the team, typically development. Even when you are running Scrum in other sections of the business the typical Agile board doesn’t show the broader value stream.  A Kanban board can cover all aspects of the business – from product conception to implementation. Put up the columns that help you understand your system. A common pattern I have implemented is using a Program or Portfolio level Kanban that feeds into various organizational units such as development, training, process, marketing, and HR. The point of this view is to show the broader system to everyone and how each area fits together in the broader view of delivering value to the customer. You can also cascade boards to show a comprehensive view of the complexity in the organization.

Limiting of WIP

Once you get work showing on your Kanban board you will see where work is piling up.  Excess work in process raises a number of challenges. It increases the time a new item will take to travel through the system. It indicates the likelihood of an overburden on the current performers or the next performers. For example, in Scrum iterations when there is a lot of work in development that all moves to test at the end of the iteration – this is undesirable.  You can limit WIP in a number of ways.  In Scrum, we limit WIP at the iteration boundary and some teams limit WIP by limiting the number of work items that can be active at any one time. The Kanban board calls for explicit WIP limits and also recommends buffer columns to mitigate the impact of variation to keep work flowing through the system. You can certainly explicitly limit WIP and include a buffer or buffers on a normal Agile board. Here is a essay from Lean Software Engineering showing ScrumBan.

Classes of Service

Kanban also introduces a concept of Classes of Service. Classes of Service are a mechanism for typing of work item types. Rather than treating each item homogenously, Classes of Service may let the team establish different prioritization policies for each class of service. Prioritization policies come into play when someone is looking to pull the next work item. For example, one class of service might always move the work item to the top of every queue. This would expedite it through the system. Another class of service might be even higher priority – with the team violating WIP limits and stopping what they are working on to pick up the item. Classes of Service can also help with the allocation of performers. For example, WIP limit policies may be established so that one new feature, three defects, and one technical debt feature will be active at all times.

Kanban boards are different then a normal Agile board

I agree with Daryl that a normal Agile board can be used to learn from the system in the same fashion the Kanban board can. There are some differences. A Kanban board can be implemented without changing any thing else and then making changes to fix the problems we see. Kanban can provide a broader view of the value stream. Kanban provides for limiting WIP and using buffers to facilitate pull and flow. Kanban supports classes of service. So, what stops a team doing Agile and using a normal Agile board from adding some columns, limiting WIP, and adding in classes of service? Nothing – except perhaps a lack of understanding. Part of uncovering better ways of developing software is to continue to learn and do what makes sense in each specific situation.

Tags: , , ,

7 Responses to “How is the Kanban board different then a normal Agile board?”

  1. Alan Shalloway says on :

    Looks like we’re thinking along the same lines. See my earlier post

  2. Chuck Suscheck says on :

    This is a really good article. Wish I had read it when I started with Kanban.

    By the way you spelled the title wrong. Should be ‘than’ not ‘then’

  3. Daryl Kulak says on :

    When you talk of hand-offs, do you mean hand-offs between the Agile team and some other team? If it is inside the Agile team room, why are we handing-off anything? Seems like a mini-waterfall if that is the case.

    The limiting WIP argument fall flat for me. I have never experienced being inside a team room and not realizing that there was a backup somewhere. How can someone be in a team room and not realize that someone has run out of work? Why would we need our board to tell us this? In a big factory, with lots of noise and machinery, I can see that happening. But in a quiet (relative to the factory) team room, who cannot notice that? It seems like a management tool possibly for people outside the team room. Is that the case? I can’t see it adding value to the team themselves, beyond what an Agile story wall provides.

    Again, thank you for patiently answering my questions here. I obviously am lagging behind in knowledge about Kanban and Lean, either that or I’m able to point out things that others are not noticing. I won’t know which until someone engages with me like you are doing now.

  4. Dennis Stevens says on :


    Thanks so much for the discussion.


    Remember, Kanban doesn’t suggest you create artificial hand-offs, it suggests you model what exists today. So if you have hand-offs you should show them – if you don’t you wouldn’t. There are three cases that come to mind where you may have hand-offs.

    1. A non-instantly available resource – This is the UX, DBA, or other specialized resource. Often times (not in a perfect world) these resources are shared among multiple teams. There are multiple ways to model this on the board – a special column, an “expand and collapse” section of a column on the board, a flag on the card with the NI resource using her Kanban. All of these can highlight the constrained resource and create visibility.

    2. Upstream and Downstream of the development team, particularly when a complex product is being developed that has integration requirements.

    3. Ball-in-court – and this isn’t mini-waterfall. As we move from understanding to building to accepting work will move from a product owner representative, to the development team, and back to a product owner representative for acceptance. I agree that these should not be over-the-wall hand-offs. They represent a shift in state with a different person on the team now taking the ball. BTW, I still like to have a business analyst and acceptance testing specialists on the team – I believe that being great at these is as important and challenging as being great at code.


    Where I have seen limiting WIP inside small team Agile useful is when the team works simultaneously on a lot of work and drops a bunch on the testing resources at the end of the sprint. You are correct that a mature small team can see this from the board or through discussion and manage the problem.

    How about when the team is also doing production support and there is unplanned work arriving at an undetermined rate? How about when a team is supporting more than one master – sometimes the legacy system and the system they are replacing? There is also the case where there are multiple teams doing work that has to be integrated at some point. In each of these cases explicit WIP limits are useful for coordination within the team and visibility and planning at the program level.

    A few points

    1. A very mature Agile team that is doing iterations and is focused on new product development probably doesn’t benefit from WIP limits inside the team and wouldn’t model hand-offs that don’t exist.

    2. Kanban doesn’t prescribe a lot – it creates visibility for the team and for management to support ongoing improvement. This is helpful for the team that is having difficulty gaining support from management for appropriate policies. This is also helpful for teams that have other constraints that make focused, self sufficient, small-team agile possible or teams that are primarily in production support. Kanban is a method for transformation – not a replacement for Scrum. In this way Kanban has helped many teams, some of whom have had difficulty getting to Scrum, achieve a higher level of maturity and implement Agile practices.

    3. There is some point in almost every product and some conditions where a higher level of throughput can be accomplished by decoupling planning, development, and acceptance from the iteration and moving to a continuous flow model for development. I write about it here In those cases, explicitly modeling hand-offs and WIP that were handled in batch around the iteration time-box is important.

    I really appreciate your questions. I don’t see this as an either or discussion. I believe small team XP/Scrum is optimal in many cases – but not in others. These discussions help drive clarity. Having a good handle on all the tools available in our tool kit makes us more valuable to our clients.

    - Dennis

  5. Daryl Kulak says on :

    So, let me summarize what I’ve learned so far.

    Kanban may be of use in the following circumstances:

    a. Larger teams where problems can be easily hidden.

    b. Teams where non-instantly available resources (inside or outside the team) could cause a backup, which we would like to make big and visible.

    c. Teams that are time-sliced or have many masters.

    These all make sense. I just need to force myself to think of the Kanban board as a way to visualize the problem situations, rather than as a tool hastily plucked from a manufacturing floor and placed into a software shop.

    For the problems above, with roadblockers (DBA, UX, etc.) or time-slicing, I can see a great need to make the issues big and visible, so I can see using a Kanban board for that.

    Thanks Dennis.

  6. Dennis Stevens says on :

    Awesome. I think that is all accurate.

    I would also add teams whose primary focus is on items that have an indeterminate arrival rate and level of complexity (i.e. defects and small enhancements) – such as a a sustaining engineering team – may be better managed with continuous flow than with iterations.

    - Dennis

  7. Paul Beckford says on :

    Hi Guys,

    The labels can sometimes get in the way. Great discussion. Just wanted to add one thing. XP “prescribed” limiting WIP over a decade ago now. The XP value of focus, and the practice of completing the highest priority story first before starting another IMHO works very well as a WIP limiting technique. Not to say that I’ve got anything against placing numbers on columns. I just wanted to correct the record. When a lot of people talk about Agile they really mean Scrum. I agree, that Scrum doesn’t explicitly limit WIP beyond the scope of an iteration. But if you think about it even with Scrum WIP is limited, but at a rather course grained level (one iterations worth at a time).

    It sounds that at #lssc11 people began to move beyond the labels. There are core principles in play here, leading to practices. The problem is when we begin to claim that any given codified set of practices are some how universal.

    A much more interesting discussion is what practices have been shown to work in which contexts and why? Even better, what practice have failed, where and why?

    These are the interesting questions. Kanban, Scrum or even XP aren’t golden hammers. They are just labels, which have been pulled and stretched until each has become almost meaningless.

    Last point. What is the difference between a Kanban and Agile Board? Depending on the team, nothing :) Now tell me what you do, and why it works for you, or better still, where and why it doesn’t.



Leave a Reply