Crossing the Kanbasm

Dimitar Karaivanov

Dimitar Karaivanov

CEO and Co-founder of Businessmap

Table of Contents:

Once in a while, people embarrass themselves publicly. As much as I hate these events, I'm no exception. One such mini-embarrassment for me was when I asked the following question on Twitter:

What's the best way to tell people that they are not doing Kanban?

Although I had the best of intentions, looking at the replies made it clear that I had something to learn. My attitude was becoming condescending and taking a few slaps in the face from people who knew better reminded me that "There's no judgment in Kanban". I couldn't have said it better than James Steele, who replied to my Tweet:

There's no judgement in Kanban

Having thought about this for some time now, I'd say that the very assumption that there's right and wrong in Kanban is something to be suspicious about. The only thing we should deeply care about is evolution. As long as we're evolving our management method, we're doing it right. It may not be a mature Kanban implementation yet, but a dozen experiments later, it will be.

Most of us take evolution for granted. It just works, no matter if we want it or not. The fittest survive, rule, decline, and eventually get replaced by the next fittest species.

It's precisely my deep belief in evolution that pushed me to ask that question on Twitter. I couldn't get why some folks start visualizing their work and never go past that phase. It almost looks as if they're standing at one side of the bridge, some twenty meters away from the other side, but they hear voices in their heads shouting, "YOU SHALL NOT PAAAASSSSS". I bet you read that with your Gandalf voice, didn't you ;-).

This bridge metaphor has been haunting me for months. It wasn't until I read Geoffrey Moore's "Escape Velocity" that I realized what was going on. I knew why people were not crossing the bridge. It's because"¦ there was no bridge!

The Chasm

Reading "Escape Velocity" inevitably reminded me of another book by the same author. A book I've labeled as my marketing Bible - "Crossing the Chasm". If you have not read this book, you are missing out. Find the time to get it, it will be well worth your time. I promise.

The chasm is what kills most startups, and it's a nasty place to be in. When a company creates a new product, it's first adopted by the two groups on the left - Innovators and Early Adopters (see the image below). Because the innovators buy any new gadget and because the early adopters are willing to spend money on innovation, they create an illusion of a growing market.

The chasm of product adoption

Image credit:

Closing those first deals provides just enough courage to bet on high marketing and sales budgets. However, revenue doesn't grow as the sales force clashes into the wall of the early majority's pragmatism. That early Majority is not willing to make compromises in the name of the great vision, something which the early adopters were passionate about. When a company finds itself in a position where all new buyers are not as excited as the initial buyers were and the existing market growth has stalled, it is probably in the chasm.

The Kanbasm

Going back to the bridge metaphor, I realized that instead of a bridge, there was a chasm. Not the type of chasm that prevents us from getting to the early majority but a chasm built by the lack of understanding, awareness, and education. The Kanbasm.

Teams get into the Kanbasm when they visualize work but they never adopt any of the advanced techniques or practices available in the Kanban body of knowledge. Simply put, the Kanbasm means no evolution.

Just visualizing work is the equivalent of those initial deals you get with the early adopters. They give you hope for a better future, only to set you up for a greater challenge later on. Sometimes we hear things like "Kanban didn't work for us" - these guys didn't manage to cross the Kanbasm and therefore did not get the huge benefit a mature implementation can bring. Sometimes you see a board that's described as a "Kanban board," only to realize it has nothing to do with a Kanban system. These guys are still in the Kanbasm and will probably stay there for ages.

The real deal comes with the early majority, which in the world of Kanban is much more than sticky notes on the wall. It's actually about flow and risk management, not just visualization. It has a lot to do with scaling Kanban across the enterprise. It's about treating organizations as a network of services and not locally optimized "agile" teams.

The scope of a deep Kanban implementation is huge and there's no practical way to present it in a blog article. Later on, we'll be talking about the Kanban Maturity Model, which is one of the best coaching tools in the Kanban world and can be used to evaluate what a mature implementation holds.

Crossing the Kanbasm

One of the key takeaways from "Crossing the Chasm" was the strategy companies could employ to get to the early majority. I'd like to remind you that you should read the book, in case you haven't done it already but here's the main idea:

  • Identify a tiny segment that you can dominate
  • Win 50% or more from that "beachhead" segment.
  • Keep expanding into adjacent segments until you become a market leader.

Isn't this another way of saying, "limit work in progress, get focussed on a few things only, and finish fast what you've started"?

So, how do we translate this to the Kanbasm, which is not about market domination but about going deeper into your Kanban implementation? What's the equivalent of the beachhead segment that we can use to "kanbanize" our company from top to bottom?

From my 9-year experience with Kanban, I have concluded that we need these 5 key elements to do the jump.

  • Business Need
  • Leadership That "Gets it"
  • Capable Change Agent(s)
  • Proper Tools
  • Results

Business Need

This one is a no-brainer but I keep talking to people attempting Kanban just because others are doing it. Kanban's goal is to help you improve/sustain customer satisfaction and, through that ensure long-term survivability and prosperity for the business.

However, if you are able to hit your goals time and time again, why bother? If you've just invented the next iPhone and you're making money out of thin air, why bother? If your customers love you and each new customer gets you ten more, why bother? As much obvious as it may seem, nothing drives deep Kanban implementation more than the real need to improve.

One of our customers, whose Japanese factory was destroyed by the earthquake that damaged Fukushima, had to compensate by improving deliveries in the three European factories. This customer had a very real, pressing need to improve. Kanban did miracles for them.

We had a customer who had to let 1/3 of their personnel go due to financial challenges. However, they needed a way to sustain the current production levels as they had contracts to fulfill. Kanban did miracles for them too.

If there's a need, there's a way, the Kanban way.  

Leadership that "Gets It"

I haven't ever seen a deep Kanban implementation without the support of a senior leader who truly buys the evolutionary Kanban method on a holistic level and has the necessary decision-making power. We're not talking about the typical team-level stuff. We're talking about a commitment to business agility on a company-wide scale.

Kanban usually starts on the middle-management level, where it brings relief from overburdening and significant improvements. However, it often hits a wall when it gets to the senior leaders, something that I haven't been able to figure out yet. Why would senior management say no to results?

I believe that the low number of senior leaders talking about Kanban is primarily driven by the lack of analyst reports on Kanban. Why that's still the case when Kanban is the obvious winner, I don't know. Still, we will likely start hearing more and more from the analysts, which should at least narrow down the gap.  

The Change Agent

Somebody has to drive the implementation, even if we have full support from the CEO. The senior leaders in the organization will not have the time to do this by themselves, as it's not a one-off project. It takes time (years) and many experiments to make your organization truly agile, that's why competent change agents are required. These are people who live and breathe Kanban and who have done it before (preferably).

Based on the size of the organization you may have just one change agent or a team of change agents. I was once a member of such a team, there were 10 of us for an organization of around 500 people. My experience being part of that team was amazingly positive and I highly recommend this approach.

Just make sure you allocate enough time for these change agents actually to do Kanban-related work. If they are occupied with their daily work, it's unlikely that they have the persistence and stamina to drive the implementation further.

Proper Tools

Tooling is probably the least important piece of the puzzle but it's still a crucial one. If tooling is in the way, it's unlikely that you get deeper in your Kanban implementation.

Coaching Tools

Besides the formal Kanban training that you can get, I want to mention again the Kanban Maturity Model as a superior coaching tool. It comprises more than 130 Kanban practices and is an amazing resource to drive deeper implementation. Of course, a maturity model will not do the job for you but it's there to guide you on your way crossing the Kanbasm.

Kanban Tools

As the CEO of "Businessmap" and one of the creators of our flagship software product - Kanbanize, I am obviously biased, so take whatever I'm going to say with a grain of salt. Still, whatever tools you're using, please make sure that they support deep Kanban and not just simple column visualization. Not every Kanban board is a Kanban system and if you're hoping to get far using Trello or Planner, you're not really serious about Kanban. Don't get me wrong - these tools are great for task management but they fall short when talking about Kanban.


If all previous elements are present but results are not, we all know what's going to happen. That's why we need to have very clear goals and KPIs to track if we doing okay or not. But please, be careful as "you get what you measure".

If you recall, we talked about customer satisfaction being a primary goal of a Kanban implementation. Keep that in mind while implementing the KPIs to track. The more your KPIs are pointed to your customer the better. On the contrary, the more you measure things that are only relevant to you, the greater the risk of not making the impact you're hoping for.

A KPI that you measure with your customers in mind would be the initial response time to a support request or the total resolution time for a given problem. On the other hand, if you measure how long it took your RnD team to start working on the issue without taking into account the actual resolution time, your customers might not be that happy about your support service.

It may take some time before you spot the first signs of improvement but once that happens, nothing is going to stop you.

In Conclusion

The key thing to take home with you, having read this article, is the fact that there's no Kanban without evolution. If you've started visualizing your work that's great! However, it's just how the journey starts!

If you've ever wanted to be Neo from The Matrix, now is the time...

You can take the blue pill and continue to believe that Kanban is just those stickies on the whiteboard.

Alternatively, you can take the red pill and follow the white rabbit in the Kanban chasm (Kanbasm). To get out of there, you'll need those five things:

  • Real Business Need
  • Leaders that get it
  • Competent change agents
  • Proper tools
  • Results

It won't be easy, Mr. Anderson, but in the end, evolution always wins.



Dimitar Karaivanov

Dimitar Karaivanov

CEO and Co-founder of Businessmap

Dimitar is a lean thinker and a Kanban practitioner with a solid background in the areas of software development and process improvement. He is passionate about achieving extreme performance at scale and applying Lean/Agile principles outside IT.