It’s usually about degrees for true and false

Recently, I heard folks at a few of my clients and at a couple conferences talking about why they are considering moving to using Kanban vs. Scrum.  I have no preference to either method other than choosing the right agile development tool for the job.  My concern derived from what I have heard identifies the beginnings of some myths and also demonstrates some of the hype around Kanban.

First, a clarification; Kanban with a capital (K) is the term David Anderson coined with respect to an agile development approach to driving change based on lean principles.  Kanban with a little (k) represents the idea of the “sign” or “billboard” that provides the signal/visibility in a production line for additional demand for service of a particular station. It is one of the tools that enables just-in-time (JIT) action as described in the Toyota Production System.

Kanban, as Anderson explains in his book, relies on change occurring in more of an optimizing manner (see kaizen culture).

David Anderson’s Kanban book

This is the significant difference between Kanban and Scrum.  In a Kanban approach, an organization can begin with their current practices with a few exceptions. Kanban requires:

  1. A high degree of visibility into the state of all work queued and in progress
  2. Absolute respect for WIP limits
  3. A commitment to execution in a ‘pull-based’ manner from the prioritized work queue

Kanban also demands a focus on quality.  In fact, this is Anderson’s first step in his six-step recipe for Kanban.  Quality comes first primarily because of the obvious cause-and-effect relationship to waste — and because it’s generally more in the direct control of technical management.  Working down his recipe, there tends to be less control and influence over the changes by technical management.

Now for the Myths and Hype

Myth:  Scrum has work pushed onto the team while in Kanban work is pulled into the system.  This is incorrect.  Scrum does not have work “pushed through the system.”  It is a pull-based agile development system with work pulled in larger batches (the Sprint Backlog).  A Scrum implementation (as well as Kanban) becomes a ‘push-based’ system when the business doesn’t respect the current proven capability of its teams to produce value and just continues to push demands for service into the system.

Doesn’t just apply to Kanban

Hype:  Kanban at its core is summarized by the premise:  ‘Stop Starting, Start Finishing’. The entire team’s focus is on ‘getting to done’ for the tasks in progress. This statement is certainly true of Kanban, but the implication that Scrum does not have this focus is not true.  Scrum done right has the same focus, delivering software sooner and doing so in priority order to maximize the value delivered to the customer. I’ve coached to Scrum teams for years that, wherever possible, everyone on the team should work on the highest priority item and get it done first before starting on the next item in the Sprint Backlog.  This implies limiting WIP, as well as focusing on delivering the Backlog in rank order.

If the focus of a Scrum team is to just get everything in a Sprint Backlog into an in-progress state, regardless of priority, then you have a dysfunctional team that’s most likely not working cross-functionally and certainly not focused on delivering the highest-value items first.

Hype: The statement, “The Kanban method is intuitive and is quickly and easily adopted by teams,” to me is a statement that’s used irresponsibly.  It is too often a battle cry of those trying to sell Kanban as a product.  It is the cop-out reason used by many organizations who are failing at Scrum and looking at Kanban.

In Part 2 of this post we’ll continue the conversation about implementing Kanban and some of fundamentals that hold back Kanban and Scrum implementations.

Related topic: What is Kanban? How is Kanban different from Scrum?


Join the Discussion

    • Melle Koning

      Great post. Indeed in both kanban and scrum the software engineers need to focus on quality. Otherwise we will have to keep fire fighting bugs of previous shipped (not shipable) software.

    • Vin D’Amico

      Excellent points! There is far too much hype around all agile approaches to software development. We have to face the reality that building great software is hard work. It is also a team-intensive activity. A good process always helps but it’s not enough.

    • Jeroen

      How can kanban best be used in a (non-IT) New Product Development process, as a better and lean alternative to traditional Project Planning using Gantt?

      • Mike DePaoli

        Hi Jeroen,

        I find the application of kanban to new product development to be very straight forward. To do so, as David Anderson recommends, first get your quality house in order. If you do quality poorly, doing it faster won’t help 😉 Next, make it visible, that is all the work in your immediate work queue and the work that is in process. This is accomplished through a kanban board. Figuring out the scope of your operation that you have adequate control over is important so that you can represent a process on your kanban board that is not outside of your control. With a kanban board in place, complete with buffers to help maximize flow, you have a tool that is much richer than an Gantt chart in conveying where things are as far as status as well as where your bottlenecks are in your process. The last of the first three steps in the Kanban recipe is apply and tune Work In Process (WIP) limits.

    • Chris Chan

      I find that there is too much “turf” war in the industry. Each camp is trying to sell their approach as being better. Whether it is Kanban, Scrum, or some other method, it doesn’t really matter. What matters is to continuously improve and adapt the approach to the situation with the goal of delighting the customer by delivering value frequently. And to do this you need to be pragmatic, rather than being too dogmatic about which method you use.

      • Frank Smieja

        Here here! Focus on quality, together with the “agile mindset” in most things you do, be it actual development of code, analysis or prioritization. Never give up and gradually infect and improve people and processes around you…

    • Rajeev

      KANBAN has restrictions which is really not practical. In real world things mostly work in parallel and not serial and taking the approach of kanban of 1 open item per developer will surely make things very slow. And things has to be made better not slow. E.g. When you are waiting for something to happen you should always be able to go ahead and take the next thing in queue and have multiple items in progress.

    • Michael DePaoli

      Hi Rajiv,

      Thanks for your comment. Note, there is nothing about Kanban that says your WIP limits require one thing in process at a time. In fact optimally, devs having two items in progress at a time is often optimal to avoid being blocked with just one.

      Having things occur ‘in parallel’ is a business / execution choice. A neuroscience fact, humans can not multi-task. Only try to get better at context switching. Little’s Law tells us the higher the WIP the lower the system throughput. In software especially this usually means lower quality too.

      • Shailesh

        I think Rajiv was referring to time sharing and not multitasking

    • Odeta

      Thanks for an objective post. See also

    • jon

      They are both quite useful. We use a Scrum strategy for developing in a feature sprint, but use a Kanban strategy when doing maintenance on software that has already been released. Kanban works great for this because it’s driven by issues the come up; these are interruptions, and you can’t plan those.

      • swbratcher

        Good insight, Jon. This is where I have arrived also.

    • Bob Lieberman

      Very good post. I would add that Scrum only functions well when everyone on the team is concerned about process and process improvement. While some product owners or scrum masters are directive in style, that is not the optimal model and it doesn’t lead to very good performance.

      Kanban, on the other hand, can function very well with directive leadership where the “workers” are interested only in getting their tasks done. Again that is not ideal, and will prevent making the end-to-end system improvements Kanban is famous for. Those improvements come when everyone on the team thinks of themselves as a system problem solver.

      If your company is resistant to Agile thinking, Scrum will fail or succeed much faster than Kanban which may never fail or succeed at all.

      If your company welcomes Agile thinking, Scrum is actually an easier path because the framework explicitly demands collective responsibility for process learning. Kanban can run forever with little collective responsibility for process learning.

    • Bob Lieberman

      Another thought… while is is indeed a common practice in Kanban for a developer to have a WIP of two (one in case they are blocked), that is actually a dysfunctional pattern that will stymie process improvement. This safety valve takes the pressure of the developer and the team to understand and remove the causes of the blocks. When all is said and done, the aim of kanban is to improve flow by sensibly removing the blocks. This is an area where Scrum may offer an advantage, because with Scrum the team has committed (or forecast) and it is up to the whole team to get a card (user story) closed. “We were blocked” is no excuse.

    22 − = 17