Discover how Kanban helps teams manage flow, limit overload, and boost delivery—no sprints, just clarity. A smart Agile option for changing work.

---

8.5.1: Konnichi-wa, Kanban

When people think of Agile, they often picture Scrum: sprints, stand-ups, and tightly coordinated teams working in short bursts. But Scrum isn’t the only Agile method. Kanban offers an even more agile approach, and for many teams, it’s a better fit.

Let’s start with the word itself. Kanban (看板) is Japanese for “signboard” or “visual card.” It began at Toyota in the 1940s, where workers on the production line used cards to signal when more parts were needed, rather than relying on forecasts or overstocking.

This simple visual system led to a phenomenon known as just-in-time (JIT) production—only building what was needed, when it was needed, and in the right amount. That shift reduced waste, improved flow, and led to one of the most efficient production systems in the world.

In fact, Kanban and JIT didn’t just transform Toyota. They reshaped global manufacturing and gave rise to the modern supply chain systems we rely on today.

That idea—pulling work based on demand, rather than pushing it out based on a schedule—is central to Kanban. Unlike Scrum, which is built around planning and timeboxed sprints, Kanban is continuous. Work moves through the system one task at a time, based on capacity.

In short, Kanban focuses on flow, not fixed roles or cycles. It’s built for teams that need to respond to work as it comes in—think:

• An IT help desk resolving irregular volumes or tickets
• An HR team handling unplanned recruitment requests
• A marketing team juggling content updates, events, and social media

These teams rarely have the luxury of neatly planned sprints. Their work is unpredictable, and priorities shift fast. Kanban gives them a way to stay organized, limit overload, and keep things moving.

Here are a few core principles behind the method:

Kanban can be used in standalone Agile or even predictive projects, but it’s just as valuable in day-to-day operations. It helps teams stay focused, avoid multitasking, and deliver a steady stream of value, without being bound by theoretical schedules or timeboxes.

In the next lesson, we’ll explore how to build and run your first Kanban board.

---

8.5.2: The Kanban board

A Kanban board is a way to track tasks visually as they move through stages.

Each card on the board represents a task or item of work, and it moves from left to right across the board as it progresses.

This gives the team (and stakeholders) a shared, up-to-date view of what’s being worked on, what’s finished, and what’s stuck.

Most boards include basic columns such as:

• To Do – tasks that are ready to be started (your backlog)
• In Progress – tasks currently being worked on
• Review or Testing – tasks that need feedback or quality checks
• Done – tasks that are complete

Depending on the work, you might add other columns, such as “Blocked” or “Ready for Release,” to make the workflow clearer.

Kanban boards can also include swimlanes—horizontal sections that split the board into different teams, work types, or product lines. You can also color-code or tag cards with labels for things like priority, size, or status.

This keeps the board clear, even when multiple streams of work are happening at once.

Let’s compare how the same project looks in a Gantt chart versus a Kanban board.

The Gantt chart

This Gantt chart shows all the planned tasks (A to G) across a 30-day timeline. Each bar represents when a task is scheduled to start and finish, and the vertical red line marks “Today” at Day 12.

Assuming everything is going to plan, we can see which tasks are:

• Completed (Tasks A and F are fully finished),
• In progress (Tasks B, D, and G are underway),
• Yet to start (Tasks C and E are scheduled to begin soon).

This Gantt chart gives a high-level plan and is useful for forecasting and managing dependencies, but it can be hard to interpret quickly, especially in fast-moving environments.

The Kanban board

Now compare that with the Kanban version. This board shows the same project work, but not by date. Instead, it focuses on where each task sits in the workflow as of Day 12.

This board uses three columns:

• To Do – tasks that haven’t started yet
• In Progress – currently being worked on
• Done – tasks that are completed

Here’s how the tasks line up. As in the Gantt chart:

• C and E are still in “To Do” — they haven’t started yet.
• B, D, and G are “In Progress” — work has started but isn’t finished.
• A and F are in “Done” — they were completed earlier in the timeline.

This view helps everyone on the team—and any stakeholders—see at a glance what’s happening right now. You don’t need to read timelines or interpret dates—just look at the board.

Both charts represent the same plan:

• The Gantt chart shows the big picture and planned timing.
• The Kanban board shows the live status of each task.

In an Agile setting, the Kanban view is especially useful for daily check-ins, quick reviews, and visual coordination, especially when work moves fast and plans change.

Why visibility matters

Many teams struggle because their work is invisible. It lives in people’s inboxes, spreadsheets, or memory, and no one knows what’s actually happening.

Kanban helps bring clarity to chaos by putting the work on the wall (or screen) for everyone to see.

This visibility means:

• People stop duplicating effort or stepping on each other’s toes
• Blockers and bottlenecks are spotted sooner
• Priorities are easier to manage and re-align

In the next lesson, we’ll explore how limiting the number of tasks “In Progress” at once can actually speed up delivery.

---

8.5.3: Limiting work in progress (WIP) and managing flow

Ever had a to-do list so long you couldn’t figure out where to start—so you started everything and finished nothing?

That’s the problem WIP limits are designed to solve.

In Kanban, WIP stands for Work in Progress. Anything that’s been started but not yet finished. And when we say “limit your WIP,” we’re not trying to slow you down. We’re helping you avoid the biggest delivery trap of all: multitasking.

The myth of multitasking

We like to think we’re good at multitasking, but the science says otherwise. Switching between tasks eats up time, focus, and energy. Instead of speeding things up, juggling too many things often slows us down.

Here’s what happens when WIP is too high:

• Tasks get started but not finished
• Work sits idle, waiting for input or review
• The team gets overwhelmed and context-switches constantly
• Blockers are harder to spot because everything looks busy

By limiting WIP, teams are forced to finish what they’ve started before taking on more. That leads to faster delivery, better focus, and a clearer sense of progress.

Spotting bottlenecks

WIP limits also make it easier to see where things are getting stuck. If “In Review” has five items but “In Progress” only has one, it’s a sign that review is a bottleneck. That gives the team a chance to investigate and adjust.

How to set WIP limits

There’s no magic number. A good starting point is:

• About one item per person for active work (e.g. if you have 3 people working, your “In Progress” limit might be 3)
• Or 1–2 items per stage depending on how your team works

You can always adjust as you learn. The goal isn’t to squeeze productivity—it’s to smooth the flow of work.

The daily WIP meeting

We’ve already discussed the daily stand-up in Scrum. In some Kanban teams—or in service-based or operational environments—it’s referred to as a WIP meeting.

The idea is the same: a quick, daily check-in to review the board, look at what’s in progress, flag anything that’s stuck, and make decisions about what to pull next.

Whether you call it a stand-up, scrum, or a WIP meeting, it’s one of the simplest and most powerful ways to keep work flowing.

It’s also a great way to reinforce WIP limits. If your team is tempted to take on something new, this meeting is where you ask: “Are we really ready, or do we need to finish something first?”

Limiting work in progress doesn’t slow teams down. Instead, it helps them finish faster by reducing overload and improving flow.

Focus on fewer things.

Finish more of them.

That’s Kanban.

---

8.5.4: Kanban vs Scrum: Different paths to progress

Scrum bakes improvement into its cycle. Teams reflect at the end of each sprint, adjust how they work, and aim to get a little better every time. That’s great when you’re delivering in set increments and have a stable team.

Kanban is more fluid. There are no sprints, no special-purpose teams, and no fixed roles. It works well in environments where work is continuous, unpredictable, or shared across multiple priorities, like IT ops, marketing, or HR.

Here’s how they compare:

Choose Kanban when:

• Work comes in continuously (like support tickets or creative requests)
• You need to respond quickly to change
• The team is juggling many work types at once
• You already have a process and don’t want to reinvent it

Choose Scrum when:

• You have a clear, evolving product or service to build
• It’s important to deliver working outputs regularly
• You want to build rhythm, predictability, and team habits
• The team is open to (or already using) Agile ceremonies

They’re not rivals—just different approaches. In fact, many teams use Scrum to deliver and Kanban to manage flow or support.

In the next topic, we’ll introduce more Agile metrics and explore how to use them without getting buried in the data. For now, remember this: small, visible changes add up, and Kanban is built to make them easier.