When implementing a Kanban strategy, we’re essentially creating a pull-based system of work. This methodology, which originated in lean manufacturing, offers teams a structured way to visualize, manage, and improve their workflow. If you’re struggling with bottlenecks, work piling up, or inefficiencies in your process, Kanban might be exactly what you need.
In this post, I’ll dive into the three core practices of Kanban, how to define and visualize workflows effectively, and the importance of work-in-progress (WIP) limits. I’ll also share personal advice on how to overcome some common challenges teams face when implementing a Kanban strategy.
What is Kanban?
Kanban is a visual system for managing work as it moves through a process. Teams using Kanban define stages in their workflow, set limits on how much work can happen in each stage, and continuously improve their process.
The Three Core Practices of Kanban
Defining and Visualizing the Workflow – Teams start by mapping out the stages that their work passes through.
Actively Managing Items in the Workflow – Teams must monitor the flow of work and take action when bottlenecks arise.
Improving the Workflow – Continuous improvement is at the heart of Kanban, and teams should always look for ways to enhance efficiency.
Defining Your Kanban System
To build an effective Kanban system, it’s crucial to first decide what system you’re going to use Kanban to monitor. Many teams define their workflow with simple columns like “To Do,” “In Progress,” and “Done.” But here’s a key point: just defining columns doesn’t make it a Kanban system.
A true Kanban strategy requires more depth. At a minimum, you need to establish work-in-progress (WIP) limits, visualize waiting states, and focus on flow management.
The Importance of WIP Limits
At the core of Kanban is the principle of limiting work in progress (WIP). Without WIP limits, you’re not really following Kanban. Why? Because WIP limits prevent teams from overloading the system and allow them to focus on finishing tasks before starting new ones.
Why WIP Limits Matter
🛑 Prevent bottlenecks: If you don’t cap the number of items in a stage, work can pile up, slowing down the entire process.
📊 Focus on flow: By limiting how much work is in progress, teams can focus on moving tasks through the system efficiently.
Example: Hospital Waiting Rooms
Imagine you walk into a hospital waiting room, but all the seats are taken. The overflow room fills up, and people start waiting longer than expected. Hospital managers might realize that they’ve booked too many patients for a particular time slot. In response, they could adjust the schedule to reduce wait times.
This is how we should approach workflow in Kanban. When we see a stage in our process filling up, it’s a sign that there’s too much work in the system and we need to adjust.
Understanding Waiting States in Kanban
Kanban also helps teams identify waiting states, or places where work stops because the next stage is full. A waiting state occurs when one stage completes its work, but the next stage can’t take on new items.
For example, let’s say your team has three stages: analysis, development, and testing. Once the analysis team finishes their part, they may place items in the development queue. But if development is already at its WIP limit, those items sit in a waiting state.
Visualizing Waiting States
To prevent work from piling up, you need to visualize these waiting states. A common approach is to create “done” columns for each stage. For instance:
Analysis Doing
Analysis Done
When items are in the “Analysis Done” column, they’re waiting for the development team to pull them into their workflow.
By visualizing waiting states like this, teams can see when work starts to pile up and take action to fix the flow.
The Problem with Push Systems
In a push system, one team might “push” work into the next stage without permission, overloading that stage. This creates chaos, as the next stage might already be full, causing delays.
Kanban, on the other hand, operates as a pull system, where each stage only pulls work when it’s ready to handle it. This ensures that the system remains efficient and prevents overload.
Actively Managing the Workflow
A critical part of Kanban is actively managing items in the workflow. Teams need to regularly review their Kanban board to identify bottlenecks and take corrective action.
Handling Bottlenecks
If a stage is getting overloaded, the team should stop and address the issue. For example, if the development team is overwhelmed, the analysis team may need to stop working until the development queue clears. This helps to avoid building up a backlog of work that can’t be processed.
🔴 Raise the red flag: If one part of the process is blocked, teams should raise a red flag and pause new work.
🤝 Collaborate: In some cases, the team from the previous stage can jump in to help. If analysis is done, they might assist the development team to clear the bottleneck.
What Happens When Teams Ignore Bottlenecks?
If teams keep pushing work into the next stage without addressing bottlenecks, waiting times get longer, and the system becomes inefficient. Imagine a done column that keeps getting larger and larger, with no one addressing the overflow. This kind of waste can seriously affect the speed at which work flows through the system.
Wouldn’t it be better if teams stopped and said, “We’ve hit our limit; let’s address this before moving forward”?
The Power of Continuous Improvement
Kanban isn’t just about managing work; it’s about constantly improving the process. If bottlenecks or waiting states keep occurring, it’s a sign that the system needs improvement.
How to Improve the Workflow
🛠 Analyze constraints: Look for stages where work gets stuck and figure out why.
👥 Collaborate with leadership: If there’s a systemic issue, bring it to leadership’s attention and work together on a solution.
📈 Measure and adapt: Use flow metrics to monitor the system and make data-driven improvements.
Applying Kanban in Scrum Teams
Interestingly, Kanban strategies can be applied in Scrum teams as well. Scrum already has a built-in pull system, where developers select work during Sprint Planning. However, adding Kanban on top of Scrum can offer an extra layer of visibility and flow management.
By breaking down the activities within a Sprint into Kanban stages, teams can see exactly where work is getting stuck and address it quickly.
Final Thoughts: Why Kanban Matters
Kanban helps teams visualize, manage, and improve their workflow by creating a pull-based system. It prevents overloading stages with work, ensures smoother flow, and provides visibility into where bottlenecks are occurring.
If you’re struggling with creating an efficient workflow, Kanban can help. Whether you’re implementing a full Kanban system or adding Kanban principles to Scrum, the key is to actively manage and continuously improve your process. 👉 Pro tip: Always set WIP limits and keep an eye on waiting states to prevent bottlenecks from derailing your progress!
When you’re implementing a Caman strategy, we’re effectively creating a pool-based system of work. So, Caman kind of does this. There are three core practices to Caman: defining and visualizing your workflow, actively managing items in that workflow, and then improving that workflow.
Our ability to define and visualize that workflow as part of creating that Caman system means we need to decide what is the system that we’re going to use Caman, a Caman strategy, to monitor. Right? So we define generally, and you’ll see this a lot with teams, as they’ll define columns. If they just stop there, it’s probably not a Caman system yet. Right? It’s not a Caman strategy if they just define the columns and then we’re done. There’s a little bit more to it than that.
Some of the minimum things that you kind of need at a minimum: you should have WIP limits. Right? At absolute minimum, you should have WIP limits. Those other things we should have, but definitely if you don’t have WIP limits, definitely not a Caman system yet.
What we’re able to do is decide what of the stages that our work flows through, but we also want to think about what are our wait states. Wait states are places where work stops because the next thing that needs to happen, the next activity, the next stage in the process is full. Right? There’s no capacity.
If you think about, I’m trying to think of a good example. A good example is if you go to the hospital and you go to the waiting room and there are no seats left. Quite often, there’ll be another overflow waiting room where people can go and wait to get into that situation. Then the people running that department in the hospital are going to be looking at how many people end up in this overflow. They’re all waiting longer than we expect because everybody’s waiting longer than we expect, and we don’t want too many things in the system. Perhaps we need to reduce the number of people that we book on a particular schedule, right, in order to minimize the amount of time people wait and maximize the amount of people we get through the system.
That’s more difficult for hospitals because they have to take into account people that cancel, people that don’t turn up, all of those kinds of things. So, yeah, that’s fun. But this idea of the wait state is really important.
So quite often for a stage, let’s use a really simple visualization where you’ve got some kind of analysis, discovery happens, then some sort of development or doing happens, and then some kind of validation or testing happens, and then things are finished. You want to be able to indicate on your board, in your visualization, in your system, visualizing your system when things are complete from the perspective of analysis. Right?
But we’ve not yet started development, doing work on it. So if the analysis team just put it into the development team’s backlog, and I’m using teams badly here, but the people doing analysis put it into the backlog of the people doing development, they’re committing to that work on that other group’s behalf. Right? They’re putting it in their system inside of their view without permission. They’re just dropping it in there. Even if they ask, they’re kind of pushing that system. That’s a push system.
If we want to create a pull system, then the folks in the stage before, so in this case analysis, they want to kind of have an analysis doing and an analysis done indication. That analysis done is a wait state for the next stage to look at that list of things that are done from the previous stage and then pull them in. But it still counts as time in that previous stage.
That way we can visually see when work piles up and see when we need to do something about it, like the overflow in the waiting room at the hospital. We want to be able to take action. Right? We want to actively manage the items in the workflow, which means we’re going to be looking for those wait states. We’re going to be looking for work piling up.
You might find if we’re limiting work in process, which we should be in a Caman system, then if the development activity has four things that they can take and the analysis activity has four things, then perhaps the analysis work stops because they have four things in done, and the development activity has more things in progress/done, and we can’t take on any more.
Analysis can’t take any more because their WIP is four, and they then stop working. They say to the system, “We don’t have anything left to do. We can’t start new work because we don’t have room in our system.” Right?
You might think, “Well, surely they can just take on something else.” But what if they keep doing that and don’t stop and put up the flag and alert that we’ve stopped work? What if they just keep going? So they keep pulling work and dropping it into their done column, and their done column just gets bigger and bigger and bigger and bigger.
Perhaps the next stage can’t pull from that list very quickly, and it means that the wait time, the amount of total time in the system for all of those things that are in that wait state is getting longer and longer and longer, and it’s just waste. Wouldn’t it be better if that group in analysis just put up the red flag and said, “We’ve stopped because we’ve got no more room in our system. The next stage has not filtered more down. What should we do?”
Right? In reality, if you’re an engineering team working together, perhaps they go help the next stage down the line. Right? Maybe they can help out and help make that faster. Or perhaps we need to bring this up as a bigger thing for leadership and say, “We’ve got some kind of problem in the system, and we need to change the system in order to make it more effective so the things that we bring into the system flow through the system more quickly.”
By creating a pull system, we actually create a system within which we can see, we can visually see when the system’s not flowing properly, when the engine’s not working properly. It will back up, and it will back up all the way to a point where we’re like, “Okay, everybody in this line of all, every single activity is effectively blocked.” Right?
It’s not a blocked thing, but everything is constrained. And then, “Oh, this is where it’s constrained because they’re still working, and everybody after them has stopped.” What’s the problem? Do we not have enough people here to be able to process the amount of work that’s going on? Are we taking on too much work into the system so it’s flowing through too quickly for this?
Whatever the constraint is in this area, we need to figure out what it is and go fix it.
This dynamic applies both for a Caman strategy. Right? You want to be looking for those stages and thinking about how do we visualize them. But it also applies in the Scrum world as well. Scrum has a wait state built in because the developers select work during Sprint planning. Right?
So that’s their moment for pulling work into the system, and then the system runs, and we see what comes out the other end. So we can apply a Caman strategy on top of that as well, in addition to the work-limited pool system that’s implemented by Scrum, and add additional work-limited pool systems so that inside of the system that Scrum creates, we can break it up into other activities that allow us to see what’s going on in those activities and where within the system that’s implemented by Scrum where the actual activities are blocked, are stuck, are constrained, that we need to take action and we need to fulfil that final part of a Caman strategy, which is improving the workflow.
Not just actively managing it, but improving it. So we need to go take action and make a change. If you’re struggling to create a pool-based system of work, then we can help you. We provide world-class Caman training from Pro Caman, as well as consulting and coaching for teams trying to implement a Caman strategy. If you’re a Scrum team, then we always recommend bringing in flow metrics as a complementary practice and have Cang classes from Scrum.org as well.
