Quite often people mention Kanban as a step up from Scrum, or as an alternative. It almost feels as if this was a binary choice and scrum and kanban were your only choices.
Nothing could be further from the truth. The reality is that there are environments in which you using kanban you can simply achieve a lot of effectiveness. But what are such environments or situations? And why would they lend themselves more appropriate for kanban?
In this post I’ll help you understand when Kanban is the easiest choice as your agile work management approach and why. I will also discuss with you the false dichotomy when people ask Scrum or Kanban.
So, whether you use a lower “k” or a “K”, why and when would you choose kanban?
if you are a video person, you can watch it on YouTube. Otherwise, let’s continue with the read.
When You Have Highly Variable Workloads
If your team faces fluctuating workloads or frequently shifting priorities, Kanban is a great fit.
As Kanban works on a pull system, which means, “don’t send me work I get work when I have capacity“, commitment is made as late as possible in the game, without compromising actual time spent doing the work. Commitment happens… as you pick the next piece of work. This will not only help you calibrate expectations about how long it takes to deliver something, but also helps you understand precisely how long it takes to actually produce it and why.
This deferred commitment of work lets you keep re-prioritizing things in your intake until it’s time to start working on the next best thing, As an example, let’s say you would normally, by the end of your current work, pick up your next blue task.
But because priorities just changed while you were still finishing something in development, now it’s fine, you get to do the pink task. No work has been set aside and interrupted because of this change in priorities. No harm no fowl.
With Kanban, teams can swiftly adjust to changes, reprioritize tasks, and keep the workflow running smoothly, no matter how unpredictable things get.
When you Want Continuous Delivery
For teams focused on continuous delivery and rapid iteration, Kanban is a good friend. By making your process have DONE as DELIVERED you are reinforcing a continuous delivery loop. Whatever exists the system, aka, gets to DONE in the kanban board, passed the test of delivery.
The point in kanban is always to get work to DONE. So while some people work prioritizing and figuring out while we should work next (Your Intake or TODO columns), the “system” ( which is a team, a department, a whole value stream, ideally) is focusing on letting nothing stand in the way of the delivery of what is CURRENTLY in progress.
The commitment for work once started is to the delivery. The commitment is not to start something new. It’s to finish what’s already in the pipeline.
That’s why you visualize everything, including the blockers, and flags, you limit WIP, you pay attention to the time it takes to complete work and try and reduce that to a minimum, never skimping on quality.
When You Focus on Process Improvement Experiments
The next situation to use kanban is whenever you are in an experimentation or improvement cycle. If your team is all about continuous improvement and optimizing the workflow, Kanban sets a great foundation.
By mapping your work processes and controlling work in it, you get data. Data as far as size of work, duration, blocking, probability of delivery dates, you name it. As you monitor, you gain insights. One of the most important tools an automated system on your Kanban board will give you is a CFD, or a Cumulative Flow Diagram.
The most important data you can get is seen here: cycle time, or the duration of your work items from start to finish, and throughput, or how much work gets completed in the pipeline for a given period of time.
Your Kanban system, when automated, is almost magical. You can notice where work is tends to form bottlenecks or where things seem to take the longest. You know your average as well as outlier times of delivery, which allows you to look into cost, forecasting. All that is good data that makes you have focused conversation with the right people about the things that matter most. You improve on things that are OBJECTIVELY causing problems in your system.
Whenever you feel things could benefit from change, help your gut feeling by collecting some data. Map your kanban system, monitor work flowing through your system and then decide how to improve next.
What Types of Work Use Kanban?
As you can imagine, any service-oriented work can benefit from kanban, such as support, operations, customer services, sales. Any request-based type of work is a natural fit. Think ticketing system approach. High rates of priority change. What was important to get finished today might not be as important tomorrow. Or one item might takes 2 days to complete versus another taking 10 days. Much easier in Kanban, as you are not bound by a Sprint duration.
What you may wonder and not know is that Kanban is also successfully used in software development and DevOps, ideally when the rate of arrival of work is subject to a lot of variability, or when you have variations in size as well, and when priorities can change a lot. It’s not uncommon to see some development teams experience the level of volatility a sales or support teams would.
But what I truly love about Kanban is how it exposes two critical aspects that every team should pursue: customer value and waste reduction.
Kanban Exposes Customer Value
We talk a lot about the first in agile: customer value. It’s not news as an idea.
When you visualize, prioritize and limit work in process always protecting the flow of value throughout the whole system, everybody can know exactly what’s going on at any given point in time, which allows anyone to intervene and MANAGE the situation.
We’re guaranteeing uninterrupted flow of value, so to speak.
Kanban Exposes Waste in the Process
Now, we don’t talk enough about reducing waste in the system. People seem to accept that “things take the time they take” or let things be “because they’ve always been done like that”, to name a few of the arguments.
But by using kanban you get to notice that, say your approval process always take too long. So it’s a clear candidate for improvement, aka, reducing waste in the system. Or say your testing, because it’s mostly manual. You could benefit from a lot of automation, reducing waste in time but also the possibility of mistakes (bad testing).
Improvement will happen by doing things differently or eliminating steps or artifacts.
The point is: waste reduction calls for proactive management, just like protecting the flow of value does. As you are measuring the process, you reveal the parts of your ways of working that are very problematic. You can improve the process, reduce or modify the steps of your kanban system and observe what changes.
Maybe now the same type of work takes less time. Or it comes out defect-free. With kanban you can definitely beat unnecessary hand-offs, delays, and rework.
Is Kanban Better Than Scrum?
At this point you could be asking yourself if Kanban is better than Scrum. Should you be using one versus the other?
My answer would be: that’s NOT the question you should be asking!
Let me put it this way: kanban and scrum can be combined if you truly wish. So they’re not so much a binary choice.
But the real question in here is: do you benefit more from a timebox approach or a flow approach?
Timebox approaches, and scrum is ONE such type, are better for research or very unknown work. Think work where you want to produce something, anything, a proof of concept… and you want to avoid the Parkinson’s Law.
“Work expands to fill up all the time allotted to it.” __ Parkinson’s Law
So if you give your team 10 days or 10 weeks, they will take just as long to complete their work. Scope increases. People keep injecting new stuff. You can see that you could benefit from a short timebox to explore just enough, just in time a particular feature. And during the timebox, the team is isolated from whoever keeps asking for new shiny things. Timebox is a tool for focus in the midst of chaos.
Flow-based approaches, and Kanban is one such approach, are there to help you with sustained development. Think of a continued healthy pace. In flow, your system, your kanban, is that pipeline through which you have a constant flow of work. You are always starting something and finishing something. You don’t have wait times to think and decide what to work on next, because that’s decided as late as possible, but before you start working on the new requirements. Planning occurs a little bit different in kanban. It’s not so much planning as you do it, and more so prioritizing and making informed decisions about what to work on next.
Despite not being text-book what people think and say about agile, Kanban allows you to chase after that great agile value of welcoming change even late in the development, for the customer advantage.
If you are interested in growing your agile skills, other than the blog and videos, consider joining the newsletter Agile Circle. It’s totally free, and you’ll receive insights in your inbox, be invited to events and workshops in our community of practice, The LAB of All Things Agile, and get first word in discounts for our paid programs and coaching.
