The difference between a Kanban board and a Kanban mindset: practical solutions to common mistakes
Why your Kanban board is not working as you expected
Let me guess, you are reading this article because you started using Kanban, driven by a new agile mindset in your company and after some initial improvement now your Kanban board is not working as you expected. Don’t worry, we have all been there.
Kanban board vs Kanban mindset
Kanban is a wonderful way to manage the development cycle, but most teams struggle to understand how to use it efficiently.
Most of the time people think they are a ‘Kanban team’ only because they use a Kanban board. But what you need is a Kanban mindset, and it couldn’t be more different than just using a kanban board.
The same happened in my previous company. The team started using a kanban board but they were not getting all the great benefits you get from having a truly Kanban mindset.
So what’s the difference between using a Kanban board and having a Kanban mindset? And what are the most common mistakes?
Here are the 4 most common mistakes:
- Use WIP as guidance rather than law
- Workflow mapping: avoid the Schrodinger ticket
- High Cycle time = slow development = let’s hire someone
- The BFT: Big Fat Ticket
Let’s see them in detail.
Use WIP as guidance rather than law
In a Kanban System (Kanban mindset)
The Wip Limit is law and when exceeded it should have the maximum level of attention from the whole team.
In a Kanban board (no Kanban mindset)
The Wip Limit is an annoying number your team sometimes exceeds and that you increase when it happens too many times.
How to solve the problem
The Wip Limit is not just a number, it is the optimal amount of work your team should work on at any given stage. Every time you increase the WIP limit without a valuable reason (see my article here on how to properly calculate WIP limits) you increase waste and reduce the productivity of your team.
As David J. Anderson says in the book ‘Kanban Evolutionary change’ (aka the Blue Bible of Kanban):
Less WIP = minor lead time = better quality.
There is causation between the quantity of work-in-progress and average lead time, and there is a correlation between increased lead time and poorer quality.
This means that every time you increase your WIP limit (when not necessary) you decrease quality.
Instead of increasing the WIP limit, you should focus on exploiting the bottlenecks (columns exceeding WIP limits too often) and remove them (read this article to learn how to exploit bottlenecks). The WIP limit is a great way to discover bottlenecks in your flow. If you increase WIP you hide the problem under the carpet.
A common reason why product managers wrongly increase WIP limits is the fear of their teams becoming idle when a WIP limit is reached. What they should do instead is to focus everyone’s attention on the clogged column until it’s cleared out.
Tip: The challenge here is to change the behavior of the engineers. The instinct for them is to pick up a new ticket every time the engineering is complete, but in a kanban mindset that is really the last thing they should do after they check all other columns and do any peer reviews their team members may need.
Workflow mapping: avoid the Schrodinger ticket
In a Kanban System (Kanban mindset)
The columns of your board precisely map your team’s workflow
In a Kanban board (no Kanban mindset)
The columns of your board have a vague resemblance of your team’s workflow
How to solve the problem
When you create your Kanban board start with what you do now. When you look at your team’s board, you should always be able to know what’s the status of a specific ticket. You should add as many columns as you need to properly map your team’s workflow.
Always talk with your developers before making any changes and ask them to describe their workflow to add/remove the right columns to your board.
We had this problem in my company where we had the acceptance column straight after a peer-review column and we didn’t map the ‘deployment’ column. In that way, you never knew if a ticket in the testing column was ready to test or still in deployment. That’s what I call a Schrodinger ticket…
The only reason for not mapping a step (e.g. deployment, ready for testing, etc..) is when the tickets move so quickly (less 1 hour) to the next stage that makes the column pointless.
High Cycle time = slow development = let’s hire someone
In a Kanban System (Kanban mindset)
You properly analyze the cycle time of your Kanban system to understand where and how you should improve
In a Kanban board (no Kanban mindset)
You look at how much time it takes to develop a feature or ship a ticket without considering the steps in the middle
How to solve the problem
First of all, let’s clarify the difference between lead time and cycle time.
- Cycle time = the time a ticket takes to move from any column to any other subsequent column (eg from ‘Ready to development’ to ‘In Testing’ or ‘In Development’ to ‘Done’ etc);
- Lead time = the time a ticket takes to move from the first column to the last column of your board (eg from ‘Inbox’ to ‘Done’).
The Lead time is a decent indicator to check the overall health of your development process and it can be useful when estimating new features development (eg. feature X took 1 month to develop, feature Y is similar to X so it should take approx 1 month to develop feature Y).
The Lead time can tell you if you have a problem (not always) but it doesn’t tell you where the problem is (bottlenecks).
To identify where the bottleneck is, you have to analyze the Cycle time of each of your columns and see where a ticket spends most of the time. Once you identify the bottleneck, you dig into the reasons for the high cycle time and solve them (learn how to identify bottlenecks here).
Also note that, often, exploiting a bottleneck unveils several problems in other parts of the board. You keep exploiting the new bottlenecks until tickets start flowing through the board quickly and consistently.
Tip: There are plenty of tools to properly analyze cycle time and lead time if you use an electronic board. My favorites are Jira for overall health and Screenful for a more in depth analysis.
The BFT: Big Fat Ticket
In a Kanban System (Kanban mindset)
You analyze and discuss each task with engineers and designers before creating a ticket on your board; no matter how easy you think the task will be and you break the task in multiple small tickets.
In a Kanban board (no Kanban mindset)
You create tickets without discussing them with your team, using your knowledge and understanding of the work needed to complete the task.
How to solve the problem
Product managers tend to be optimistic when it comes to delivering the right solution to a problem, often underestimating the size of a ticket. Every task must be discussed with your team, it doesn’t matter if you think it’s just a small task. Ideally, a ticket shouldn’t take more than 1 working day of development (you can adjust this based on your workflow, but I found that 1 day of development works pretty well in terms of ticket sizing).
In almost all features and tasks you can find hidden traps, flows you didn’t consider or technical challenges that only your engineers will be aware of. Never skip the discussion and always break tasks into smaller tickets to avoid the BFT (Big Fat Ticket).
In my experience, the most common situation in which you (unconsciously) create a BFT is when after developing a feature, you realize you forgot some additional details (maybe you initially deprioritized them in your MVP) and you quickly create a ticket to cover them. After 4–5 days in development you realize that you should have discussed the ticket with the team.
In Conclusion
We saw how Implementing Kanban is not just about using a Kanban board. It needs a radical change in how you approach development, efficiency, and waste. Don’t be afraid to enforce stricter rules on your team and always remember to discuss any change with your team to get them on board. Kanban is a collaborative process and cannot work without the commitment of the whole team.
Remember, using a Kanban board is easy, but changing human behavior is not.
Thanks for reading! I am writing a book on product management, if you liked this article and you’d like to be notified when the book is out or when I write a new article, follow me on medium!
