Solving the 7 most common Kanban mistakes that ruin your development

In Agile, working in Kanban is like Scrum but without the sprints. Without sprints, your team can react faster.  You complete a piece of work, and immediately check if you can move on to the next ticket. 

This is ideal if your team does work where it’s important to react fast, such as customer support or dealing with maintenance requests.  

Kanban can feel easier than Scrum, because you don’t need to follow the strict, prescriptive discipline of Scrum ceremonies. But this freedom also makes it more difficult to do Kanban really well. If you think you need less discipline with Kanban, you are wrong — you need more discipline. 

So to help you do Kanban right, and not let the freedom spiral into inefficiency, I am now going to share some critical advice that will save you resources and peace of mind.  

The principles of good Kanban

First, by following these general principles, your team can’t go too wrong with your Kanban.  

1. Set and obey work in progress (WIP) limits for process steps
2. Do not push work downstream if there is not enough capacity (if the downstream process steps have reached the WIP limits)
3. Define what is needed for moving work from one process column to the next
4. Remember to also integrate into your ways of working: refinement, high-level planning, and learning

The most common problems, and how to avoid them

Having advised companies on Agile work for many years, me and my colleagues have seen it all. And we would like to share with you the seven most common Kanban problems out here, and how to fix them. So read on and avoid the pitfalls. 

1. You are hoarding tickets

Kanban is a method for visualizing the workflow. It works by limiting the work in progress. Kanban comes from the Toyota Production System and car factories. If you work in a car factory, you can’t pull cars off the production line and store them next to your workstation. You would get nothing done if your workstation looked like a supermarket parking lot.

Why then, do software teams feel they can work differently? Why is it so common to see a Kanban board full of tickets? 

In fact, the process WIP limit is one of the most common Kanban rules that is broken. Most Kanban teams do not even have a WIP limit, and those that do, rarely follow it to the letter.

What to do instead 

• Obeying a strict WIP limit is difficult. Even if you feel unable to obey a limit, the team should at least acknowledge the need that less WIP is better. 

• Ensure that team members work on one thing at a time, and before starting anything new, check how the downstream process looks. Is downstream flooded? Rather than add to the flood, investigate what you can do to help.

2. There is no refinement

In a Scrum team, regular ceremonies are the rule. Regular, weekly refinement sessions are no different. With Kanban, the ceremonies are no longer dictated. The routine disappears. 

Because Kanban works with ticket flow, it is too easy to start working on an unrefined ticket. 

This leads to:

• Starting work on too-large tickets

• Waste — the work is moved to the “in progress” column, and the team trusts a singular developer to refine the ticket as he also starts implementing it.

What to do instead

• Set up a regular backlog refinement session also for Kanban teams

• Ensure a good “Definition of Ready” discipline

• Use a refinement Kanban board, or add a refinement column to the work board to visualize when tickets are under refinement

• Enforce size estimation and size limits for starting new tickets

3. You are too focused on development

Kanban teams typically focus too much on the development and testing columns. They often forget to keep demos or seek feedback from users and other stakeholders. 

In Scrum, the sprint review forces the team to consider the results, and how completing something impacts the backlog and future plans. The demo part of the review also actively invites feedback. This discipline is missing in Kanban, and needs to be introduced back to the team’s calendar.

Do this instead

• Schedule regular demo sessions also for Kanban teams

• Consider adding a “feedback needed” column to your Kanban board

• Be alert if the team starts to focus too much on implementation, and too little on feedback

4. You are using the default Jira workflow

The default Jira workflow of “To do” - “In progress” - “Done” should be forbidden. It has several serious problems, such as:

• You can’t see which tickets are new, and which ones have been approved by the Product Owner to be on the backlog. Product Owners must have control over backlog approval. They need to make the yes/no decision and also position the items in the correct priority order. 

• You can’t indicate if the item needs refinement, or if it has been refined and is ready to be worked on (passing the Definition of Ready filter). By simply using the “Todo” as a state for the complete backlog, there is no way to control the refinement. So work often starts on unrefined tickets.

• If an item is moved to Done, people assume that the work is completed. But you can’t see if the item has been demoed, if you are waiting for customer feedback, and which items have been released, or are waiting for release. What about code reviews or design reviews?

Do this instead

• Consider the following process steps as Kanban board columns: New, Needs refinement, Ready for implementation, Review, Feedback needed, Waiting for demo.

• Make your Kanban board reflect your true process – this is what Kanban is all about!

5. You don’t have rules for transferring tickets downstream

Good Agile teams have two quality criteria, Definition of Ready (DoR) for starting work, and Definition of Done (DoD) for completing it. In addition to this, better Kanban teams discuss and set rules for moving things from one Kanban column to the next. 

Consider the mini-DoD

For example, in my last Kanban-using team, when moving a ticket from the “Development” to “Testing” column, the developer ensured the following:

• Functionality works as desired and is defined in the acceptance criteria

• The developer’s own testing passes and no known bugs exist

• Code compiles without warnings

• Unit tests are done and pass

• Design documentation is updated in Confluence

• Testing instructions are provided for the test engineer

• The developer and tester have a handover chat

With this agreement (mini-DoD), we reduced much of the back-and-forth between tester and developer, smoothing the workflow through the team’s process.

Again, think of the car factory. Each downstream workstation has to be able to trust that workers in the previous stations always perform the work in the same way.

Do this instead

• Define mini-DoD’s for each of the Kanban column transfers

6. You suffer from ticket blindness

In Kanban, it is easy to focus too much on individual tickets, and lose sight of the big picture. For example, in team dailies, the team members tell each other what they are doing. Then later on, when you encounter a situation where team members should understand what others are working on, it is clear they were not listening. 

Ticket blindness causes each team member to only focus on their own tasks.

Swarming on a problem is a powerful way to solve tough problems. When people are too focused on their own tickets, they can sometimes miss situations that require swarming an issue. 

Ticket blindness is especially dangerous when the team is mostly remote.

Kanban can cause single-person silos

In Scrum, because the team has to think about the sprint, and what the whole team can achieve in the sprint, this blindness to others’ work is less of a risk. And the sprint goals also align the team to work together.

Do this instead

• Keep an eye out for issues that require swarming to solve 

• Make sure your Product Owner gets the team to understand the big picture and upcoming work (backlog refinement and “scan and plan” methods help here)

• Set up regular planning sessions with the Kanban team to keep people aligned around a bigger target

• Ensure that people are listening in dailies, not daydreaming

• Consider setting monthly targets or other forms of intermediate goals to help the team navigate

• Be extra vigilant to avoid single-person silos in all-remote team setups

7. You don’t hold retrospectives — so you are not learning

In Scrum, you typically have a certain rhythm for retros. The official Scrum guide says to have the retro in the last meeting of the sprint — but nothing stops you from holding extra retros at other times so experiment and find out what works for your team. 

By not having this rhythm, Kanban teams can easily forget to hold retrospectives. 

Do this instead

• Book regular retrospectives, six months in advance

• Have them at least once a month, if not more often

• Value and keep the retro meetings, do not skip them

Kanban that actually works

Kanban can be more fun and motivating for a team that works in a very dynamic environment. But while Kanban may appear easy, do not take this for granted. Great Kanban requires more discipline than Scrum. A good Scrum Master helps the Kanban team to keep improving.

We hope this list of seven things to avoid helps your Kanban team improve.