From Batch-Mode Delivery to Continuous Flow
It’s been more than 2 decades since the Agile Manifesto, but many organizations are still operating in a batch-mode delivery model:
- requests are gathered in batches
- work is handed off between functions
- analysis, development, and testing are separated
- delivery is governed through stage gates and approvals
So a practical question arises: What does it actually look like to introduce Kanban into that environment?
Here’s the approach:
- Visualize the current workflow. Map how work actually moves today.
- Break large batches into independently movable features. Introduce a smaller delivery unit that can flow through the system.
- Allow features to move individually between workflow states. Stop requiring the entire batch to complete a phase before anything can progress.
- Apply WIP limits and pull signals. Now that individual work units can flow, regulate how much is active.
- Observe where features accumulate and age. Let the system reveal its real constraints.
- Iteratively improve the system. Use what the flow reveals to redesign the system.
Start With Reality
The first mistake many organizations make is trying to introduce an “ideal” Agile workflow immediately.
They design a clean board:
Backlog → Ready → In Progress → Done
…and attempt to impose it on a system that does not behave that way.
This usually fails.
Because the existing system is not structured for flow.
It is structured for handoffs, specialization, and batch progression.
So the correct starting point is not elegance.
It is truth.
Step one is to visualize the current workflow exactly as it operates today.
What a Batch-Mode Workflow Usually Looks Like
When mapped honestly, a typical delivery system often looks something like this:
Request → Analysis → Requirements Approval → Design → Development → Test → UAT → Release Approval → Production
This is not yet a Kanban system. It is simply the current process made visible.
And in many organizations, these are not true flow states.
They are phase containers through which large batches of work move together.
Once the system is visualized, a number of patterns usually become obvious very quickly:
- large queues between stages
- work items that are too large to move predictably
- heavy reliance on handoffs
- long periods of waiting between active work
At this point, no redesign has occurred.
But something important has happened: The system has started to tell the truth.
Break the Batch Before Trying to Control the Flow
In a traditional phase-gate environment, work often does not flow at all.
It moves in large synchronized batches.
An entire initiative may sit in Analysis until the analysis phase is declared complete. Only then does the batch move to Design. Then Development. Then Testing.
Under those conditions, simply applying WIP limits to the current workflow may have little immediate effect.
Why?
Because there is no meaningful downstream pull yet.
If 100% of the work is still trapped in Analysis, then downstream states are empty—not because the system is healthy, but because the work has not yet been structured to flow.
This is the first important realization:
Before you can regulate the flow, you must create something that is capable of flowing.
That usually means introducing a smaller delivery unit.
A useful starting point is the feature.
Instead of moving an entire project or release scope through the system as a single batch, the work is decomposed into smaller, meaningful units of value—features that can progress independently.
This creates the first real break from batch-mode behavior.
Instead of waiting for an entire phase to finish, individual features can begin moving between workflow states as they become ready.
That is when flow begins.
A Practical Next Step: Introduce the Feature as the Unit of Flow
Once the current system is visible, a deeper issue usually becomes clear:
The work itself is too large to flow predictably.
In a batch-mode environment, work typically moves like this:
- entire projects move through analysis
- then the same batch moves through design
- then development
- then testing
- then release
At any point in time, 100% of the work sits in a single phase until that phase is declared complete.
This creates the appearance of orderly progress.
But in reality, nothing is flowing independently.
Value is not being delivered incrementally.
It is being accumulated.
Breaking the Batch
A useful next step is to introduce the feature as the basic unit of delivery and allow individual features to move through the system independently.
Instead of moving an entire initiative through each phase as a single batch, the work is decomposed into smaller, meaningful units:
- customer-facing capabilities
- product features
- independently testable slices of functionality
Each feature can then:
- enter the system independently
- progress through stages at its own pace
- complete without waiting for the entire batch
This is the first real break from phase-gate thinking.
What Changes
Once features begin to flow independently, several important things happen:
- queues become visible at the feature level
- bottlenecks can be identified precisely
- work-in-progress becomes governable
- delivery becomes incremental rather than all-or-nothing
Instead of asking:
“Has the development phase completed?”
you can now ask:
“Which features are finishing—and which are aging?”
That is a much more useful control question.
Now Introduce Control
Only after individual features are able to move through the workflow does it become meaningful to introduce stronger control mechanisms.
At that point, you can begin to apply:
- work-in-progress (WIP) limits
- pull between stages
- aging observation
- flow time measurement
Now the system begins to behave differently.
Work can no longer be pushed forward endlessly as a batch.
Features move individually.
Queues become visible.
And the system begins to reveal where it is actually constrained.
This is where real learning begins.
When Is Work Actually “In Progress”?
This is where many teams get confused.
In a batch-mode environment, work exists long before it is actively being delivered:
- a request is logged
- a business case is created
- analysis begins
- funding is approved
So when does the “In Progress” clock actually start?
The answer is:
When the organization makes a real commitment to deliver the work.
Not when the idea appears.
Not when the request is logged.
But when the system chooses to carry it.
This is the commitment boundary.
Two Different Time Signals
It helps to distinguish between two related but very different delivery signals:
1. Cycle Time
How long does it take an item to complete once it has entered the delivery system?
Cycle Time measures:
In Progress → Done
This is a historical performance measure. It tells you how completed work has behaved over time.
2. Aging In-Progress
How long has a currently active item been in progress so far?
Aging measures:
time elapsed since entering In Progress, for work not yet completed
This is a live operational signal. It tells you how long the system has been carrying active delivery risk for a specific item.
Together, these two signals are extremely useful:
- Cycle Time tells you how work has been flowing
- Aging tells you whether current work is behaving normally or showing signs of delay
This is why Aging is such a powerful control signal.
It allows the system to detect trouble before missed delivery dates or stalled releases make the problem obvious.
Where the Aging Clock Should Start
If Cycle Time is measured from In Progress → Done, then the important question becomes:
When does an item truly become “In Progress”?
The answer is:
When the organization makes a real commitment to deliver it.
Not when the idea appears. Not when the request is logged. But when the system intentionally begins carrying the item as active work.
This is the commitment boundary.
Even if it passes through multiple states such as:
- analysis
- design
- development
- test
- approval
These are not separate commitment boundaries.
They are sub-states within a single delivery system.
From that point onward:
- Cycle Time will eventually measure total elapsed time to completion
- Aging In-Progress will measure how long the item has been active so far
That is the point where delivery risk truly begins to accumulate.
Why This Matters
Once you start measuring aging in this way, the system becomes much clearer.
You begin to see:
- where work is truly delayed
- where queues are forming
- where handoffs are slowing progress
- where capacity is constrained
And very often, a deeper issue emerges:
many features are still too large to flow effectively.
That is the point where real redesign begins.
Not by introducing more planning.
But by reducing the size of work, limiting what is active, and improving how the system behaves.
What Happens Next
Once the current system is visible, the next step is not immediate reorganization.
It is to create the conditions for flow.
That usually begins by:
- breaking large initiatives into smaller features
- allowing features to move independently
- observing where those features stall or accumulate
- then applying stronger control through WIP limits and pull
Only then does the deeper redesign work become meaningful.
At that point, the system starts to reveal:
- where work is too large
- where handoffs create delay
- where capacity is constrained
- where structural redesign is needed
This is how a batch-mode system begins to evolve into a flow-based delivery system.
Not by replacing one framework with another.
But by gradually replacing batch progression with controlled feature flow.
Final Thought
Kanban does not require a perfect Agile system to begin.
It does not require new roles, new ceremonies, or a new framework.
It requires something simpler:
Make the current system visible.
Break large batches into smaller units of flow.
Observe where those units accumulate and age.
Then begin regulating the system.
From there, the system will tell you what needs to change.
The first job of Kanban in a batch-mode environment is not to make the system look Agile.
It is to make the system tell the truth.
Get a Free Consultation
If your delivery system feels overloaded, slow, or coordination-heavy, a short review can help identify where flow may be breaking down — before committing to a larger engagement.
This is a practical, low-risk way to explore whether a deeper diagnostic or consulting engagement would be useful.