What Does Kanban Mean? Origins, Principles, and How It Works

Your Team Has Probably Been Doing Kanban Without Knowing It

Ever stuck a Post-it note on a whiteboard and moved it from “To Do” to “Done”? Congratulations. You’ve done the most fundamental thing in Kanban. That simple act of making work visible and tracking its movement through stages is exactly where this method starts.

But Kanban is more than sticky notes on a wall. Behind that simple visual system sits a set of principles that changed how Toyota built cars and eventually how software teams build products. Understanding the meaning behind the method gives you a much better shot at actually making it work.

The Word Itself: What Kanban Means in Japanese

Kanban (看板) is a Japanese compound word. “Kan” means visual or look. “Ban” means board or card. Put together, it translates to “visual signal,” “sign board,” or simply “card.”

In its original manufacturing context, a kanban was a physical card attached to a bin of parts on the factory floor. When workers used up the parts, they’d send the card back upstream as a signal to produce or deliver more. No card, no production. That’s it. The card was the signal that controlled the flow of work and materials.

This simple idea of using visual signals to control workflow is the foundation everything else builds on.

The Toyota Origins: Where Kanban Started

In the late 1940s, Toyota engineer Taiichi Ohno had a problem. Japanese manufacturers couldn’t compete with American mass production. They didn’t have the resources to build large inventories of parts and finished goods the way Ford and GM did.

Ohno found inspiration in an unexpected place: American supermarkets. He noticed that stores only restocked shelves when items were purchased. They didn’t push excess inventory onto the floor. They let customer demand pull products through the system.

He adapted this “pull” concept for manufacturing. Instead of pushing parts through the assembly line based on forecasts, Toyota used kanban cards to signal when a downstream station needed more parts from an upstream station. Each card represented permission to produce or move a specific quantity.

The result was the Toyota Production System, which dramatically reduced waste, cut inventory costs, and improved quality. It became one of the most studied manufacturing systems in history. And the kanban card was at its heart.

From Factory Floor to Software Teams

Fast forward to 2007. David J. Anderson was working at Microsoft and noticed that the same problems plaguing manufacturing (too much work in progress, unpredictable delivery, bottlenecks) were showing up in software development.

Anderson adapted Kanban principles for knowledge work. Instead of physical cards controlling the flow of car parts, he used visual boards to control the flow of software tasks. The core idea was identical: make work visible, limit what’s in progress, and let demand pull work through the system.

What made Kanban appealing to software teams was its gentleness. Unlike Scrum, which asks you to adopt defined roles, ceremonies, and sprint cadences from day one, Kanban says “start with what you’re doing right now.” No revolution required. Just make your current process visible and start improving it incrementally.

That low barrier to entry is why Kanban spread so quickly through the software industry and into other knowledge work like marketing, HR, and operations teams.

The 4 Foundational Principles of Kanban

Kanban has four principles that guide how you adopt and apply it. These aren’t rules to memorise. They’re a philosophy about how change should happen in your team.

1. Start With What You Do Now

Kanban doesn’t ask you to throw out your current process and start fresh. You map your existing workflow as it actually is, not as you wish it were. This means no disruptive day-one overhaul. You literally draw your current process on a board and start tracking work through it.

This matters because resistance to change usually comes from fear of the unknown. When you start by reflecting what already exists, there’s nothing to resist.

2. Agree to Pursue Incremental, Evolutionary Change

Big-bang transformations rarely stick. Kanban favours small, continuous improvements over dramatic overhauls. You try something, observe the result, and adjust. Over time, these small changes compound into significant improvements.

This is the opposite of what many “Agile transformations” attempt, where an entire organisation tries to flip a switch overnight. Kanban’s approach is slower to show results but far more likely to last.

3. Respect the Current Process, Roles, and Responsibilities

Kanban doesn’t prescribe roles. There’s no “Kanban Master” or mandatory role changes. Whatever titles and responsibilities your team currently has, you keep them. This removes the political friction that comes with reorganising teams around a new framework.

Over time, roles might evolve as the team improves its process. But that evolution happens organically rather than being imposed from the outside.

4. Encourage Acts of Leadership at All Levels

Improvement isn’t just a manager’s job. Kanban explicitly encourages everyone on the team to identify problems, suggest experiments, and drive change. The person closest to the work often has the best insight into what’s slowing things down.

In practice, this means the developer who notices a bottleneck in code review has just as much standing to propose a solution as the team lead does.

The 6 Core Practices

While the principles tell you the philosophy, the six practices tell you what to actually do.

1. Visualise the Workflow

Put your process on a board. Each column represents a stage of work (like Backlog, In Progress, Review, Done). Each card represents a work item. Everyone can see what’s happening at a glance. You can’t improve what you can’t see.

2. Limit Work in Progress (WIP)

Set a maximum number of items allowed in each column at any time. If your “In Progress” column has a WIP limit of 3 and there are already 3 cards there, nobody starts new work until something moves forward. This is the practice that makes the biggest difference and the one teams resist the most.

Why does it work? Because humans are terrible at multitasking. Every additional item in progress increases context switching, reduces focus, and slows everything down. WIP limits force you to finish things before starting new things. That single behaviour change improves delivery speed more than almost any other process tweak.

3. Manage Flow

Watch how work moves through the system. Where does it get stuck? Where do cards pile up? How long does it take an item to go from start to finish? Managing flow means actively monitoring these patterns and addressing bottlenecks rather than just hoping things keep moving.

4. Make Policies Explicit

Write down the rules. What does “Done” mean? What’s the criteria for moving a card from one column to the next? Who can pull work? When policies are unwritten, everyone operates on different assumptions. Making them explicit removes guesswork and reduces conflict.

5. Implement Feedback Loops

Build regular points for reflection into your workflow. This might be daily standups, weekly reviews, or monthly retrospectives. The format matters less than the consistency. Regular feedback loops catch problems early and create opportunities for improvement.

6. Improve Collaboratively, Evolve Experimentally

Use data from your board and feedback from your team to run small experiments. “What if we lower the WIP limit in code review from 5 to 3?” Try it for two weeks. Measure the result. Keep what works, revert what doesn’t. This is how Kanban teams get better over time without big disruptive changes.

Setting Up a Basic Kanban Board

Whether you’re using a whiteboard with sticky notes or a digital tool, the setup follows the same logic.

Start with three columns: To Do, In Progress, Done. That’s the simplest possible board and it works surprisingly well for many teams. You can add complexity later, but starting simple gives you a working system on day one.

Add WIP limits. A good starting point is to set your “In Progress” limit to the number of people on your team minus one. So a team of five would start with a WIP limit of 4. Adjust from there based on what you observe.

Create cards with enough detail. Each card should have a title, a brief description, and ideally who’s working on it. Colour coding by type (bug, feature, task) adds another layer of visual information without cluttering the board.

Expand columns as needed. As your team matures, you might split “In Progress” into “Development” and “Review.” You might add a “Ready” column between “To Do” and “In Progress” to separate prioritised items from the full backlog. Let the board evolve to match how your team actually works.

WIP Limits: The Part Everyone Skips (and Shouldn’t)

Here’s a pattern that plays out on nearly every team that tries Kanban. They set up the board. They start moving cards. They skip WIP limits because “we need flexibility.” And then nothing actually changes.

Without WIP limits, a Kanban board is just a to-do list on a wall. It looks nice but it doesn’t change behaviour. WIP limits are the mechanism that forces the team to stop starting and start finishing. They’re the difference between “tracking work” and “managing flow.”

Will it feel uncomfortable at first? Absolutely. You’ll hit the limit and someone will have nothing new to start. That’s the point. Instead of starting something new, they help unblock whatever’s stuck. They pair with a colleague on a review. They clear a dependency. The team starts finishing things faster because everyone is focused on moving existing work forward rather than piling up new work.

Start with limits that feel slightly restrictive but not impossible. You can always adjust them once you see how work flows through the system.

Kanban Is a Starting Point, Not a Destination

The real power of Kanban is that it meets you where you are and helps you get better from there. It doesn’t demand a transformation. It asks for visibility, discipline, and a willingness to improve one small thing at a time. The meaning of Kanban, both the word and the method, comes back to the same idea: make work visible and let that visibility drive better decisions.

Frequently Asked Questions

What is the difference between Kanban and Scrum?

Scrum uses fixed-length sprints, defined roles (Product Owner, Scrum Master, Developers), and prescribed ceremonies. Kanban uses continuous flow with no sprints, no required roles, and WIP limits to manage throughput. Scrum is more structured. Kanban is more flexible. Many teams end up using elements of both.

Is Kanban Agile?

Kanban aligns with Agile values like responding to change, delivering incrementally, and continuous improvement. However, Kanban technically predates the Agile Manifesto by decades. It’s often grouped under the Agile umbrella because it’s used alongside Agile methods, but it originated independently in manufacturing.

Can Kanban work for non-software teams?

Absolutely. Kanban works for any team that manages a flow of work items. Marketing teams, HR departments, legal teams, operations groups, and even personal task management can benefit from Kanban’s visual approach and WIP limits. The principles are universal. Only the specific workflow columns change.

What are good WIP limit numbers to start with?

A common starting point is to set the WIP limit for your “In Progress” column to the number of team members minus one. For a team of six, start with a WIP limit of 5. If that feels too easy, lower it. If work keeps getting blocked, raise it slightly. The goal is to find the point where the team is busy but not overloaded.

Do you need special tools for Kanban?

No. A whiteboard and sticky notes work perfectly for co-located teams. For remote or distributed teams, digital tools like Trello, Jira, or Azure DevOps provide Kanban board functionality. The tool matters far less than the discipline of using the board consistently and respecting WIP limits.

How is Kanban pronounced?

It’s pronounced “KAHN-bahn” with equal stress on both syllables. The first syllable rhymes with “con” and the second with “bon.” It’s a Japanese word, so the vowel sounds are short and clean.

What metrics should a Kanban team track?

The two most useful metrics are cycle time (how long a work item takes from start to finish) and throughput (how many items the team completes per week). Lead time (from request to delivery) is also valuable for understanding the full picture. Tracking these over time shows whether your process improvements are actually working.

Is there a Kanban certification?

Yes. Kanban University offers certifications like KMP (Kanban Management Professional) at different levels. These can deepen your understanding but they’re not required to use Kanban effectively. Most teams successfully adopt Kanban without anyone on the team holding a formal certification.