Agile Transformation with Kanban — Revisited

Most Kanban implementations focus first on making work visible. Teams introduce physical or digital boards to visualize the workflow and improve transparency.

Visibility is essential. But visibility is not control.

A delivery system only comes under control when it actively regulates how work enters, flows through, and exits the system.

The Missing Piece

Many organizations believe they have implemented Kanban because they can see the work.

They have improved the data plane—the part of the system where work is created, refined, developed, tested, and released.

But the control plane often remains largely unchanged.

Without an explicit control plane, delivery teams continue to operate much as they did before. Work accumulates. Bottlenecks emerge. Priorities change. Dependencies grow. Meetings become status updates rather than decision-making forums. Although the work is now visible, the system itself is not being actively regulated.

Continuous flow requires more than visibility.

It requires control.

Data Plane vs. Control Plane

The distinction is familiar in modern computing.

The data plane performs the work.

The control plane regulates how the work flows.

The same distinction applies to enterprise delivery.

Data Plane

  • Strategy formulation
  • Discovery activities
  • Development
  • Testing
  • Deployment
  • Release

Control Plane

  • WIP policies
  • Pull policies
  • Aging policies
  • Flow metrics
  • Flow Reviews
  • Management decisions

One performs the work.

The other regulates the system.

Traditional Agile Transformations

Many Agile transformations begin by redesigning the delivery process.

Teams are reorganized.

Ceremonies are introduced.

Roles are redefined.

Backlogs are restructured.

Tooling is replaced.

Architectural improvements are planned.

These are all worthwhile activities.

But they primarily improve the data plane.

The assumption is that better processes will naturally produce better outcomes.

Sometimes they do.

Often they don’t.

Because the organization has attempted to optimize a system that is still operating without effective flow control.

A Control-Plane-First Introduction

A safer approach is to establish the control plane before attempting major process optimization.

Rather than immediately redesigning how work is performed, first regulate how work enters, flows through, and exits the system.

A practical introduction looks like this:

  1. Visualize the current workflow.
  2. Introduce WIP limits and pull policies.
  3. Establish regular Flow Reviews (Daily Stand-up, ART Sync, Portfolio Review).
  4. Observe flow signals such as WIP, Aging, Cycle Time, and Throughput.
  5. Take corrective action based on those signals.
  6. Improve the delivery process as the system stabilizes.

The objective is not immediate optimization.

The objective is to establish a closed-loop control system.

Stabilize Before You Optimize

This represents a subtle but important shift in thinking.

Most transformations begin with process improvement.

A Flow-based transformation begins with system stabilization.

Once work intake is regulated and regular control reviews are in place, the system begins to settle.

Only then do the true constraints become visible.

Only then can improvement efforts focus on the bottlenecks that genuinely limit flow.

Instead of relying on intuition or organizational politics, improvement becomes evidence-based.

The Role of Flow Reviews

Flow Reviews are not status meetings.

They are the controller within the delivery system.

Their purpose is to answer a simple question:

“Is the system operating within its expected limits?”

When the answer is “yes,” the best decision is often to leave the system alone.

When the answer is “no,” leaders intervene by reducing WIP, re-sequencing work, removing dependencies, or reallocating capacity.

The objective is not to manage every work item.

The objective is to regulate the behavior of the system.

Why This Matters More in an AI-Assisted World

AI is dramatically increasing the speed at which software can be produced.

The primary constraint is no longer writing code.

It is deciding what to build, limiting work in progress, managing dependencies, and making timely decisions.

As execution accelerates, the need for an effective control plane becomes even greater.

Organizations that continue to rely primarily on periodic planning events may find themselves overwhelmed by increasing delivery capacity.

Organizations with a well-designed control plane can continuously regulate flow, respond quickly to changing conditions, and improve predictability without increasing coordination overhead.

Final Thoughts

Kanban is often introduced as a visualization tool.

Its greater value lies elsewhere.

It provides the foundation for an enterprise control plane that continuously regulates the flow of work.

Perhaps the first objective of an Agile transformation should not be to redesign the delivery process.

Perhaps the first objective should be to bring the delivery system under control.

Only then does meaningful optimization begin.

Scroll to Top