Have you ever seen a Scrum team proudly presenting their Kanban board with dozens of columns and sticky notes wandering from person to person? I have. And each time I feel like I’m watching a slow-motion disaster – something I call “Kanbanosis Acute.” It’s like watching someone trying to ride a bicycle while playing an accordion – theoretically possible, but why torture yourself like that?
Tech Lead: “I’m afraid you’ve got Kanbanosis Acute.”
Junior Dev: “Is it serious?”
Tech Lead: “You’ve started organizing your unit tests, coffee orders, and emotions into To Do, Doing, and Done.”
Combining Kanban with Scrum is one of those ideas that seems sensible at first glance. After all, both approaches belong to the Agile family, right? The problem is that it often leads to more confusion than benefits, and in extreme cases, can be one of the reasons for the collapse of Scrum teams and the retreat from Agile in organizations.
Why Kanban and Scrum Form a Toxic Marriage?
Scrum was inherently created to deliver value when solving complicated and complex problems. Kanban, on the contrary – for simple and repetitive tasks.
Sprint vs Flow – a Fundamental Conflict
Scrum is based on sprints, which by design start “clean” (no work in progress) and end “clean” (everything planned is completed). It’s like preparing meals for the entire week on Sunday – clean refrigerator at the beginning, full of food containers at the end.
Meanwhile, Kanban is a continuous flow, where tasks flow through the system like water through a pipe. When we try to force Kanban flow into sprint frameworks, we lose the main advantage of Kanban – the ability to measure flow consistency. It’s like trying to measure river flow, but only during specific weeks of the year – the data will be incomplete and not very useful.
Flow Stabilization at the Cost of Inspection and Adaptation
The desire to stabilize flow in Kanban often leads teams to extend sprints. “Hey, maybe let’s do three-week sprints instead of two-week ones to better manage flow?” – I’ve heard this many times. The problem is that longer sprints mean fewer opportunities for inspection and adaptation – fundamental elements of Scrum.
It’s like less frequent doctor visits – you might feel better because you hear bad news less often, but it doesn’t mean you’re healthier.
Team as a Unit vs Individual Columns
In Scrum, the team should be treated as one entity with shared responsibility. Everyone wins or loses together. Meanwhile, Kanban, especially in its traditional form, encourages creating columns corresponding to different stages of work, often assigned to specific people or roles.
“Analysis,” “Development,” “Testing,” “Deployment” – each column is a potential silo, and tasks are passed between them like a hot potato. Handover of work in the context of one team simply makes no sense – it’s like passing a ball between your left and right hand.
Specialization vs Cross-functionality
Building columns and assigning people to them makes it difficult for the entire team to collaborate. When we have a “Testing” column assigned to testers, developers naturally focus only on the “Development” column. This leads to specialization, which is the opposite of cross-functionality that we strive for in Scrum.
It’s like having someone at home responsible solely for vacuuming, and another only for washing dishes. They might be experts in their narrow fields, but what happens when one of them gets sick?
Most Common Mistakes When Using Kanban in Scrum
Too Many Columns
The simplest and most common mistake: creating too many columns. I’ve seen boards with columns such as “To Do,” “Analysis,” “Design,” “Development,” “Code Review,” “Testing,” “Documentation,” “Deployment,” “Done.” This isn’t a Kanban board, it’s a subway map!
In most cases, three columns are enough: “To Do,” “In Progress,” “Done.” Anything beyond that often introduces artificial divisions and encourages handovers instead of collaboration.
Obsession with Flow Metrics
Kanban offers many metrics: lead time, cycle time, throughput… Teams often focus on these metrics at the expense of what really matters – delivering value.
“Our cycle time decreased by 15%!” – great, but are customers happy with the product? Are we solving the right problems? Metrics are like a thermometer – useful for diagnosis, but they don’t cure the disease by themselves.
Push Instead of Pull
In true Kanban, tasks are “pulled” through the system, not “pushed.” However, in practice, I often see developers finishing their task and immediately moving it to the “Testing” column, even if testers are already overloaded with work.
It’s like throwing more dishes into the sink even though it’s already full – instead of helping with washing. Real Kanban requires discipline and respect for work-in-progress (WIP) limits, which are often ignored.
When Not to Use Kanban
Complicated Tasks
Kanban works great in predictable, repetitive processes. Software development is rarely like that. Each task may encounter unexpected problems, require deeper understanding, or a change in approach during implementation.
It’s like using a recipe for experimenting with new dishes – you might have a list of ingredients and steps, but the real magic happens when you deviate from the recipe and improvise.
Tasks Requiring Collaboration of Multiple Specialties
If your team doesn’t consist exclusively of “full stacks” (100% fullstack-QA-SEC-OPS), Kanban can lead to silos and delays in handovers. Modern software development requires close collaboration between different specialties, not sequential handover of work.
Pursuing Goals Instead of Tasks
User Stories, Epics, and Features are not tasks, they are user goals. Kanban is great for managing tasks, but not goals. When we try to force user goals into Kanban frameworks, we often lose sight of the real objective – delivering value.
When to Use Kanban
Repetitive Tasks
Kanban was born in Toyota factories, where processes are repetitive and predictable. It works great in service operations, industrial production, or other scenarios where tasks are similar and well understood.
Simple Tasks in Large Quantities
If you have hundreds of simple, similar tasks (like flipping a coin or assembling boxes), Kanban can help manage flow and identify bottlenecks.
Tasks Executable by Any Team Member
Kanban works best when any task can be taken up by any person on the team. Otherwise, bottlenecks form and tasks wait for specific people, which negates the benefits of smooth flow.
Sum of Compliance with the Above Criteria
Kanban is worth using only when 100% of the tasks meet the above criteria. Otherwise, we risk creating a system that works well for part of the work but hinders the rest.
Additional Reasons to Avoid Kanban in Scrum
Dilution of Team Responsibility
Kanban can lead to thinking “it’s not my task,” where everyone is only responsible for their column. This undermines the fundamental principle of Scrum about the team’s shared responsibility for delivering value.
Loss of Sprint Transparency
Sprints in Scrum provide a clear timeframe and scope of work, which facilitates planning and managing expectations. Caring about flow causes work to be transferred between sprints and final stages to overlap with the beginning of the next sprint. This in turn destroys team predictability and can slowly degrade business trust in development.
How to Avoid Kanbanosis Acute?
The best is… don’t do it, but if you must use elements of Kanban in Scrum, here are a few tips:
- Keep the board simple – three columns are often all you need.
- Maintain team collaboration – avoid assigning columns to specific people.
- Respect WIP limits – this is a fundamental principle of Kanban, without which it loses meaning.
- Don’t abandon Scrum ceremonies – Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective are still key.
- Remember the goal – delivering value is more important than beautiful flow charts.
Summary
I am a huge fan of Kanban – really! It’s a powerful tool that revolutionized industrial production and can be extremely effective in appropriate contexts. However, in software development with an Agile approach, where collaboration is required, not handover, Kanban often introduces more problems than solutions.
Instead of blindly combining Kanban with Scrum, consider what you really want to achieve. If your goal is better work visualization, perhaps a simple board with three columns is enough. If you want to improve flow, maybe it’s worth focusing on reducing the size of User Stories and better team collaboration.
Remember that methodologies are tools, not religion. Use them wisely, adapting to your needs, but don’t forget the fundamental principles behind them. For Scrum, these are transparency, inspection, and adaptation. For Kanban – visualization, limiting work in progress, and flow management.
And if you ever notice symptoms of Kanbanosis Acute in yourself or your team – excessive multiplication of columns, obsession with flow at the expense of value, or handover of tasks instead of collaboration – know that there is a cure. Sometimes the best solution is to return to basics and remind yourself why we use these methodologies in the first place.
Because ultimately, it’s not about whether you use Kanban, Scrum, or any other methodology. It’s about whether you effectively deliver value to your customers. And that requires collaboration, adaptation, and continuous learning – regardless of what you call your process.