The Six Core Practices

Everything starts with visibility. If you can't see it, you can't manage it.

A Kanban board makes work visible—what's in progress, what's waiting, what's blocked. But visualization goes deeper than a board:

• Visualize work items: Cards representing actual work
• Visualize workflow: Columns showing the stages work passes through
• Visualize policies: Explicit rules about how work moves
• Visualize blockers: Visual indicators when work is stuck
• Visualize capacity: How much work each stage can handle

We'll cover this deeply in Module 2.

This is the most counterintuitive practice, and the most powerful. By doing less at once, you finish more overall.

WIP limits are constraints on how many items can be in a given stage (or the whole system) at once. When a limit is reached, you can't start new work—you must help finish something first.

This creates flow, reduces context switching, and surfaces bottlenecks. Module 3 covers this in depth.

With work visualized and WIP limited, you can now manage how work flows through the system.

Managing flow means:

• Measuring lead time and cycle time
• Identifying and addressing bottlenecks
• Smoothing batch sizes
• Reducing wait times

The goal is predictable, sustainable delivery—not heroic sprints. Module 4 covers flow metrics.

Implicit rules create confusion and conflict. Explicit policies create clarity.

Every column on your board should have clear policies:

• What does "done" mean for this stage?
• Who can pull work into this stage?
• What happens when someone is blocked?
• How are conflicts prioritized?

Policies don't have to be complex. "Code review requires two approvals" is a policy. "Blocked items get a red flag and discussion in standup" is a policy.

Kanban defines seven cadences—regular meetings for different feedback purposes. Unlike Scrum's prescribed events, these are recommendations you adopt based on need.

The key cadences include:

• Daily standups (flow focus, not status reports)
• Replenishment meetings (prioritizing new work)
• Delivery planning (when and what to release)
• Service delivery reviews (how are we doing overall?)

Module 5 covers these in detail.

This ties back to evolutionary change. Improvement isn't a one-time event—it's continuous and experimental.

Use the scientific method:

1. Observe the system (flow metrics, blockers)
2. Form a hypothesis ("Reducing WIP limit in code review will speed up delivery")
3. Experiment (try it for two weeks)
4. Measure the results
5. Adapt (keep, modify, or revert the change)

Failed experiments aren't failures—they're learning. The only failure is not experimenting at all.