Kanban: Empowering Agile Development

Every development team I've worked with has tried Kanban at some point. Most of them do it wrong — they put some columns on a board, move cards around, and call it agile. But Kanban is much more than a visual board. It's a philosophy about how work flows through a system.

What Kanban Actually Is

Kanban originated in Toyota's manufacturing process in the 1940s. The word literally means "visual signal" in Japanese. The core idea is simple: visualize your work, limit what's in progress, and optimize the flow.

But simplicity doesn't mean easy.

The Core Principles

1. Visualize the Work

This is the part most teams get right. Put your work on a board with columns representing stages: To Do, In Progress, Review, Done. But here's what most teams miss — the board should represent your actual workflow, not some idealized version of it.

If your code goes through development, code review, QA, staging, and deployment, your board should have all those columns. Hiding complexity doesn't eliminate it.

2. Limit Work in Progress (WIP)

This is the principle that separates teams that do Kanban from teams that do "Kanban theater." WIP limits are the most important — and most ignored — aspect of Kanban.

Why WIP limits matter:

Context switching is expensive. Every time a developer switches between tasks, they lose 15-25 minutes of focused work. A developer with 5 tasks "in progress" isn't working on 5 things — they're working on 1 thing badly while 4 things wait.

How to set WIP limits:

Start with a simple rule: no more than 2 items per person in progress at any time. Adjust based on what you learn.

3. Manage Flow

Once you can see your work and you've limited WIP, you can start optimizing flow. Track these metrics:

• Lead time: How long from request to delivery?
• Cycle time: How long from starting work to delivery?
• Throughput: How many items delivered per week?

These numbers tell you more about your team's health than any standup meeting ever will.

4. Make Policies Explicit

Everyone on the team should know:

• What does "Done" mean?
• What's the review process?
• What happens when a WIP limit is hit?
• How do we handle urgent items?

Write these down. Put them next to the board. Review them regularly.

5. Improve Collaboratively

Kanban isn't a one-time setup. It's a continuous improvement process. Regularly ask:

• Where are bottlenecks forming?
• Are our WIP limits right?
• Is our workflow accurate?
• What's blocking flow?

Kanban vs. Scrum

The inevitable question. Here's my take:

Choose Kanban when:

• Work arrives continuously (support, maintenance, ops)
• Sprint planning feels forced
• You want to improve without a major process change
• Your team handles multiple types of work

Choose Scrum when:

• You're building features with clear deadlines
• The team is new to agile and needs structure
• Stakeholders expect sprint-based delivery
• You need forced prioritization

Or use both. Many successful teams use Scrum for feature development and Kanban for maintenance and support.

Common Mistakes

No WIP Limits

A Kanban board without WIP limits is just a to-do list on a wall. The limits are what create the pull-based system that makes Kanban work.

Too Many Columns

If your board has 12 columns, you've over-complicated things. Start simple and add columns only when you discover genuine workflow stages.

Ignoring Blocked Items

When an item is blocked, it should be visible and urgent. Don't let blocked items sit quietly — they're destroying your flow.

Not Measuring Anything

If you're not tracking lead time and throughput, you can't improve. You're just moving cards around and hoping for the best.

Getting Started

1. Map your current workflow honestly
2. Create a board that reflects reality
3. Set conservative WIP limits
4. Track lead time and throughput
5. Review and adjust weekly

Kanban isn't a silver bullet. It's a mirror that shows you how your team actually works. And once you can see clearly, you can start improving deliberately.