Debunking the Biggest Myths About Kanban

I am writing a book about Kanban and Agile transformations. Just a few weeks ago, someone said to me: “But how can you write a whole book about Kanban?”

During the past years, I have been coaching quite a few agile transformations, often implementing Kanban. More than once, people have asked me: “Why Kanban? Are we not going to do real agile – we are not a small support team!”.

These two examples reveal three big myths about Kanban:

1. Kanban is just a few columns on a whiteboard where a lot of sticky notes are moving back and forth at random.
2. Kanban only works in small support teams.
3. Kanban is not “real Аgile”.

I want to debunk these three Kanban/agile myths (there are more, by the way) and I hope to make it clearer that Kanban can be applied wherever you use your head to produce and deliver services - knowledge work, professional services etc.

Just think about it for a minute. Isn't this what all the people in IT do? And our colleagues in the Project department, Legal department, HR, Marketing, and so on? Would that then mean that Kanban can be used everywhere?

Yes, absolutely! These days, most employees in most companies are doing service delivery of some kind, and Kanban can be put to good use and create transparency literally everywhere in your organization. And what’s more: it scales!

But back to the 3 myths:

Debunking Myth #1

Kanban is just a few columns on a whiteboard with a lot of sticky notes moving back and forth at random

It’s easy to just say “NO” this is not at all correct, but let me explain:

The workflow

One of the reasons that many have the impression that Kanban contains only 3 columns: Requested, In Progress, and Done, is the fact that other agile methods apply simplified workflow only. As a result, many believe that this is “the right process” when you work in an agile way.

This is backed up by software systems that were never built to fit the Kanban principles and practices. Some systems contain a “Kanban module” with some default process steps but lack the support for waiting columns and other Kanban techniques and practices, such as Kanban classes of service that make the method work as intended. This leads people to think that “this must be Kanban”.

Both examples are quite a bit away from where you should be when you work with Kanban. Your Delivery Kanban Board should contain all the process steps that a task/ticket goes through from the time it is placed in the Input Queue until it leaves the board after having been verified and quality assured. AND don’t forget the discovery/upstream part of Kanban, where activities are qualified and prioritized.

Work-in-progress limits

This first myth contains another common misunderstanding, namely that: Lots of tickets move back and forth at random.

Well, the whole purpose of Kanban is to optimize flow. I.e. getting as many tickets across the board in as little time as possible. The most important factor for improving flow is to have as little as possible going on in your Kanban system at the same time while keeping everybody in your team adequately busy.

Work-in-progress limits help create balance in your Kanban system by making the team capacity fit the demand for that capacity, and will keep you from task switching, which only creates delays.

So, to sum up, sticky notes do not move at random. They move from left to right, according to the rules you and your team has set up for prioritization, level of importance etc. to create the best possible pull system signals and thus optimize flow.

Debunking Myth #2

Kanban only works in small support teams

Over and over again, I have talked to teams that could not believe that Kanban would be useful for them. These teams might be development teams, teams with one particular area of focus, project teams, or teams outside IT, just to mention a few.

I’m not sure where this misconception started, but my guess is that since Agile emerged out of IT and Scrum was mainly seen as the thing to use in software development, what would be left for Kanban, was IT maintenance and support teams (check out the main differences between Kanban and Scrum here).

Your guess is as good as mine, but knowing what Kanban has to offer any team that does service delivery, maybe backed up by a software system that was initially built to support Kanban, I do get frustrated when the question pops up. But I have found that the way forward is to explain that Kanban can be used anywhere if you can answer these 4 question:

1. What work activities do you have?
2. Are some of them more important than others?
3. How does work items/activities enter your “system”, or arrive at your or your team members’ desks?
4. What happens to those work items from you receive them until you have finished all the work you need to do on them before passing them on to someone else or deploying them?

This usually makes it clear to people that there is a much wider area where Kanban can be used, and as mentioned, it scales. The advantage of scaling is that the more parts of an organization that use Kanban, the more you will be in control of your end-to-end processes. Furthermore, the principle of transparency also offers you the possibility to get a good look at the dependencies, blockers, interfaces etc. that exist between teams, organizational units etc.

To conclude: Kanban, of course, works well in small support teams, but you would be doing yourselves a big disservice if you do not let Kanban spread further out in your organization. The wider the better, allowing you to all speak the same language.

Below you see how an organization using Kanban might structure their meetings and communication flow:

Debunking Myth #3

Kanban is not “real” Agile

Some are debating whether or not Kanban belongs in the agile family. However, it cannot be debated that Kanban is an alternative path to agility in organizations.

From practical experience, I know that once you get control over your processes, and know where your bottlenecks are (this could be teams blocking each other, wait time for decisions, or ambiguity in prioritization etc.) and if you react on these findings, you will automatically become more agile. The result will be faster service delivery in a better quality, teams that are not overburdened, and customers that are more satisfied. All of this pointing towards better financial results.

If you (maybe in parallel with your physical board) have a software system supporting the way you want to work with Kanban, it only takes minutes to measure progress in lead times, the time you waste on waiting for blocked items to be unblocked, flow efficiency etc. This gives you an indication of the progress that you have made on your way to higher agility. One small step after the next.

Other agile methods sub-optimize on the team level, but struggle when it comes to handling cross-team dependencies, or scaling to the program or strategic level. I suggest that rather than optimizing single teams, it will give you more value to optimize “your system”. This is what Kanban does. Until you actively handle dependencies, interfaces etc., you will not get much benefit of having one super productive team when their deliverables are just queueing up by the next bottleneck.

But you have to start somewhere, and starting on the team level might be a good first step if it is your intention to continue with the next team and so on, and from there maybe, continuing to the program, portfolio, and strategic level.

Once you have transparency in your system, both good and bad will come to the surface, and it gives you the opportunity to react to what you see. This is sometimes easier said than done, as it may break old patterns of management, project management, team autonomy etc., and usually requires a different set of behavior.

On top of that, some find transparency hard to accept. Both on the team and the managerial level. But transparency is the key to organizational agility and a prerequisite for making your Kanban system work to your benefit.

To conclude, Kanban is a different way of boosting agility in your organization and a very powerful one too. Kanban gives you a lot of options, so you can choose the way that fits your organization best. But there are some rules that must be followed if you want to realize the possible benefits.

Final Words

As an independent consultant, agile practitioner and specialist, my only concern is to get the agile solution in place that will work best for my clients. I also like simplicity. By debunking some of the Kanban myths, I hope I have inspired you to take a good look at Kanban and the benefits of introducing a method that can work from top to bottom in your organization, without changing all the good things that you do now.