4 Signs Your Kanban Implementation Is Screwed

Kanban is a really effective tool that can help you visualize your work… when implemented correctly. I’ve been working on introducing and coaching Kanban lately, and I’ve found it’s not easy to make a smooth transition. If you are starting to use Kanban on your team, there are a few warning signs you should look out for that can signal that your implementation might not be going so well.

Warning #1: You have 30 minute conversations about the color of the card, the name of the columns, or how to filter out tags.

“What color should we make that task? Blue? No, we have blue already. Let’s do red. No red’s an issue. Can we tag it instead? How do we filter on tags?”

If your team would rather debate what color the card should be than talk about ways to get their tasks done, something is very wrong. There’s a term for this. It’s called bikeshedding. Bikeshedding is where we debate about trivial issues and ignore the things that actually matter. If your team has a habit of bikeshedding, then they are not using the Kanban effectively. All conversations should revolve around how we’re going to get the work done, where are we, and what we can improve. Of course at the beginning of an implementation, you’ll need to get the structure down. But, if it’s been 3 months and these conversations are still dragging on, you have a problem.

Warning #2: You don’t talk about goals or progress during standup.

Every morning we have a kanban standup that looks at the work to be done on the board and what everyone has accomplished the day before. After standup, we talk about where we can improve our workflow, which is usually apparent on the board. One day I noticed that we have been talking about what we’ve done each day, but I still wasn’t sure if we were making progress towards our goal or not. If Kanban’s purpose is to visualize your work, you need to make sure you are also visualizing progress. Otherwise, how can you tell if you are doing the work well? If your teams don’t have concrete evidence that they are making progress, it’s time for management to go back and set some measurable goals and communicate them.

Warning #3: Cards miraculously appear in doing.

The flow of our boards usually goes Backlog > Next > Doing. When a team member needs more work, they can move a card from Next into Doing, as we have already planned and prioritized those items. I’ve seen many times where we get into standup and find new cards in Doing that were never in Next. Of course really important issues might come up and you’ll need to deal with them, but this doesn’t happen every, single day. Teams that bypass the planning and jump into the work are often struggling with prioritization. Also, executives could be asking for many quick, unplanned favors that require the teams to context switch too often. Cards being created in Doing is a huge sign this could be happening to your team.

Warning #4: You make cards to remind you to deal with problems with the cards.

This is another form of bikeshedding. When one of my teams was doing continuous improvement on their kanban board, they would routinely come up with experiments that involved making a card to remind them to fix the problems with the other cards. For example, we saw that one team was having trouble with prioritization. So they decided to do an experiment to implement goals for the cards. Then cards appeared on the board that reminded them to set goals for the cards. This type of inception can lead to really complicated boards and take the focus away from getting the work done.


There are many underlying causes for these warning signs. Some I was able to mention, but a lot of it goes deeper. While I can’t diagnose every cause without working directly with your team, I’ve found the most of the common ones were these:

  • Kanban could be the wrong tool.
  • Your team might not be ready for it yet, meaning they cannot grok the concepts.
  • Your team cannot self organize.
  • Your team does not know how to prioritize.
  • There is no system for handling new work or quick tasks assigned by management.
  • Managers are not harnessing the valuable data they can get from the Kanban board.

and the one we rarely account for but is the mother of all problems

  • You did a really bad job explaining the purpose of the tool, which is above all, to visualize the work.

Every team is different, it may be a combination of these causes that are inhibiting your kaban paradise, or it could be primarily one. Teams also take some time to get adjusted to new tools, and that should be considered. If you’re experiencing any of these signs after a few months though, something needs to change. It’s better to recognize the warning signs early so you can act.

10 thoughts on “4 Signs Your Kanban Implementation Is Screwed

  1. I’ve got something similar from AgileInAFlash, asking how we know an agile team is circling the drain (card #36).

    We also recognized “under the table work assignment” as a problem — listed here as work appearing in “doing.”

    Also we recognized the emptiness of ceremonies, which you cover here with not talking about goals and improvement, and fighting over colors, shapes and sizes of cards.

    We had a few different ones after that, dealing with individual work assignments (not really a Kanban thing, more of a teamwork thing), inventory piling up, sacrificing quality for speed.

    We mentioned “guarded speech” (which resonates very well with the Safety Prerequisite of Modern Agile) and which of course is ironic related to 2016 events on social media. It is very important that all viewpoints can be heard without pillory. That’s not always the case.

    Hopefully we can all learn to hear voices we disagree with, or from people we didn’t choose or approve, and respond with curiosity and learning rather than with disdain and shaming.

    Any community which is not learning openly, without blame and competition, is indeed circling the drain.

  2. Really enjoyed this. Thanks for sharing your honest experiences. I’ve seen similar signs (opportunities? challenges?) in my work with teams.

    I love how visualizations make it easier to have conversations about these kinds of issues and the improvements that can come of them. It can be really empowering.

  3. Melissa,
    I am sure you didn’t want to reduce Kanban to just the visualization and the board, but at the moment, this post expresses just this. Especially if you are using limits on your WIP, you will get into discussions about work coming in from the side and proritization very quickly and make major headway on the improvements. Making policies explicit, implementing feedback loops and managing the flow will help you further along.
    I certainly wouldn’t jump to the conclusion that Kanban isn’t the right “tool” to use too quickly.
    And, on a side note, deciding to implement Kanban is usually also a management decision. We should involve the team as well, but the goal is better management of what we are doing now. Giving the people ownership over their processes is an important aspect, giving them reason and permission to improve is even more important (“Encourage acts of leadership on all levels…”).
    In the Kanban community, we have a name for what you are describing: a shallow Kanban implementation. Making it deeper involves mangement, customers and individual contributors in agreement, respect and understanding.

    • Hi Florian –

      The team I was talking about was just starting out with Kanban, so focusing on visualization of the work until they get that part down was really important. This post wasn’t meant to reduce all of Kanban down to just visualization, but I’ve had more success implementing a few rules, then adding on others as needed. That’s also how I was coached to coach Kanban, by someone you know very well :). Just like with the Product Management, Agile, Lean, Lean Startup, and UX things I teach, when I’ve come in with guns blazing and give them everything at once, then it’s overwhelming. We had explicit policies with the team above, but they were added on once they realized they were making progress and needed something more. Responding to needs to the team.

      I don’t mean this post as a stellar example of a team doing everything right or actually implementing everything right from the beginning, I think that’s the point. But it’s important not to overlook how many people are using Kanban primarily as a visualization tool. That gives the opportunity for the Kanban community to help teams evolve into something more. No one’s going to get it right on the first try, but you have to start somewhere. That’s just my approach.

      The team I’m working with now asked for help setting up a Kanban board, and then they asked for help making it better. We were able to do all the things you stated. But it’s also a team that has permission to improve. The other team didn’t. They were mandated to work a certain way, and they were rebellious. I see that a lot in teams, and I don’t think it should be discounted about how you implement things. It’s been a long time since I wrote this in 2014, so I’ve also learned a lot and grew with my own understanding of Kanban.

      I know the title is antagonistic, but it was meant as click bait 😉 It worked.

  4. Hi, I loved this post in all its honesty. I think too many people think that implementing kanban or other groovy method puts an end to the problems. Kanban needs work too. We’ve got our started about 16 months ago and it’s been hard work, I must say. But we do see results. When we were first getting going, I studied these pages a lot: http://kanbantool.com/kanban-library/getting-started, this was a good introduction. But after half a year, we got our own consultant, as working good a process by ourselves prooved too much. It’s no shame to ask for help 😉
    Looking foward to your next articles!

  5. […] 4 Signs Your Kanban Implementation Is Screwed […]

  6. Thanks for this post I was able to identify some problems in my team from here. So now I know I’m screwed… any ideas how to address these issues?

    • Plenty, but the problem is that every team has a different root cause (which is why I didn’t get into the solutions too much in this post). I’d first start here: who decided to implement the Kanban? Was it the management team? Is the team actually excited about using it? Many teams have had Kanban imposed on them by the management team who created the board for them, and didn’t give the team much say in how they can use and operate it. If this sounds like you, you might want to involve the team in a restructure of the board to fit their flow better and get them involved in actually creating it so they feel like they have ownership. If this doesn’t sound like you, then like I said, it could be lots of root causes and that’s where I come in as a consultant :) But feel free to email me and I might be able to help more (melissa [at] produxlabs.com).

Leave a Reply