5 arguments against Kanban

(image by Saltatempo)

When you’re thinking about using Kanban to manage your value flow, you will hear some tough arguments against it.  This is normal and not related to Kanban, it happens with every change initiative.  I’ve compiled a list of questions and arguments I had to deal with when introducing Kanban and some ways to respond to them.

1.  It will take longer!

People are concerned that switching to a continuous flow model, without timeboxes or iterations, the work will take longer in the end.  After all, most managers have heard about Parkinson’s law which states that Work expands so as to fill the time available for its completion.

This is a valid concern.  An average team will have difficulties keeping a strong focus as they would have in an iterative cycle where there’s always a demo lingering in the near future.  Fortunately there are ways to work in a continuous flow and still keep a strong focus.  For instance, you could implement a cadence.  Every x weeks we give a demo to our stakeholders.  Whatever is finished at that time will be shown to them.  Our measurements will be used to set expectations.  If your stakeholders know that by average you deliver 6 features per week, they expect to see 6 finished features in the weekly demo.
Another way to stimulate focus is to visualize the trend of your average lead or cycle time.  When the average time is rising, something is wrong and we can investigate together.  When the average time is falling, the team is on a roll and will get even more energy by seeing this visually.
Conclusion:  Highly mature teams will keep their focus in my experience.  We can help average and low mature teams to focus by using techniques such as cadence or visualization.

2.  We lose our ability to plan

Switching from estimating to measuring will always trigger this reaction.  How can we make commitments to our customers if we have no estimate about the effort?

Truth is, not much has changed.  In Agile we already used velocity as a measurement to correct our plan to reality.  In Kanban we’re using measurements to make our plan.
Off course you have to be able to extrapolate your first measurements to create a release plan which you can regularly correct to reality.  There are two simple ways to do this.  Split all features so that they are more or less the same size, or assign a relative weight to all features.
That way you can use your measurements of average lead or cycle time to calculate how much time is needed to complete the remaining features of your next release.

3.  High architectural refactoring costs

If we pull one feature at a time, nobody will have time to think about the architecture of the system and will just build on top of the existing.

This argument will probably not come from an Agile team, since they already know about the feasibility of an emerging architecture.  It’s not different in a flow model than it is in an iterative cycle.  Technical tasks need to be taken care of in each feature and refactoring is an ongoing effort.  I’m not saying it is easy, but you can learn how to do this.

4.  Things will get stuck – we can’t keep WIP limits

When you come with the message that only x number of feature can be in progress, and the limits cannot be broken, people start to panic.  They know from experience that some features stay in progress for a long time because they’re waiting for something outside of their control.  The idea of respecting the limit and do something else doesn’t stroke with our beliefs and the way we were raised.  You have to stay busy all the time and do your best!

But!  In the case of a pull system like Kanban, respecting the WIP limits is a powerful thing.  If you’re stuck and can’t start a new task, a short time later, the stage in front of you will get stuck too and so on.  This creates and immediate problem for the entire system, and is no longer limited to you alone.  Sure the WIP limits will be uncomfortable in the beginning, but they will create action fast!  Together you will find a way to unclog the system and finish work, instead of just starting another task and finish nothing.

5.  Our stakeholders don’t care about feeding the flow

They want all the features to be delivered as quickly as possible.

In this situation you want to go to the root cause.  Why don’t they care about prioritizing the input queue?  They probably don’t see the value it creates.  They might never had the option to change and adapt while development has started.  Explain that a plan is outdated immediately after it is created due to new insights, changing market situations, etc.  Some features are not that urgent anymore, while others may become more valuable.  Being able to quickly change the scope of your next release gives you an enormous competitive advantage because you’re able to match customer’s expectations more accurately.

 That’s my list of 5 arguments against Kanban and some options to respond .  If you happen to know some others, I’m very interested to hear about them.

About Nick Oostvogels

Hi, I'm an independent management consultant. My biggest strengths are located in the fields of teamwork, motivation, leadership and continuous improvement. In the IT industry you find a lot of these values in the agile movement, in which I often act as a project leader, product owner or coach. My interests go a lot further, into other industries where we find these values in lean production. Besides that, I try to broaden my horizon as much as possible, always looking for better ways of doing business.


  1. Great article! To add some flexibility to #4 you might add an expedite lane for high priority, unforseen events. Mature customers will most likely use this less frequently over time.

  2. Great post.

    One thing to remember is WIP limits are there to provoke a conversation, teams can always elect to break a WIP limit and defer improvement, they just need to track the decision and agree to reflect on why this happened, how they can get the WIP back down, and how they can improve so that it doesn’t have to happen again.

    Kanban allows team to take two steps forward, one step backwards…

  3. Hello Nick,
    Your post is very interesting ! I have translated it into french :


  4. Hi Nick, Must say great post. Do you mind if i put an attempt to create a video with some inputs from your post?


    • Sudheer,
      You’re free to use the content of the blogpost in any way you like, as long as you mention the source.
      What kind of video do you have in mind?

      Glad you like the post!

  5. I’m liking your post more and more.

    Here’s a couple of minor points:
    re. #1 and the “loss” of sprints/iterations: There isn’t anything about Kanban that says you -must- give up sprints. If they prove useful, by all means use them. As I understand it, a common reason for jettisoning sprints is a need to include very different classes of work (often expressed as different SLAs). In that case, a sprint length can get in the way.

    re. #4 – cannot respect WIP limits. You are exactly right, Kanabn’s transparency brings about change very effectively, for a healthy organization. However, transparency only -exposes- problems but cannot fix them. Fixing them often requires leadership.

    • Bob,

      Thanks for taking the time to comment on my blog post!

      You’re absolutely right, although Kanban is often reffered to as a continuous flow, nothing states that you can’t have sprints (or a cadance, to name it more general).
      In my experience timeboxes are often used for the wrong reasons, succesfully. So people are not eager to give them up.
      If they’re used for the wrong reasons, cadance in Kanban will make as little sense as in any other type of process.

      I agree on #4. As a lot of experience reports on Agile adoption stated years ago, exposing issues is easy, fixing them is a very different game.

  6. Pingback: 5 arguments against Kanban « Sumu's Web Link Collection

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: