DVS Improvement Flow

A delivery system produces two distinct types of value. Features deliver what the organization uses — functionality, technical capability, services. Continuous improvement work delivers something different: a delivery system that evolves — sensing shifts in conditions, adapting how it operates, and staying fit for purpose as the world around it changes.

These two types of work follow different logic. A feature is done when it can be used. An improvement is done when changed behavior is established — when new ways of working are operating consistently in practice, not when an initiative is formally closed.

Because the done criteria are fundamentally different, the flow is fundamentally different. Improvement work requires its own system, its own stages, and its own definition of completion.

Continuous Improvement as a Flow

Continuous improvement — known in lean thinking as Kaizen — is the mechanism by which a delivery system evolves. Not a one-time redesign, not a transformation program, but an ongoing process of sensing, adapting, and embedding change.

Living systems survive by adapting. A species that cannot respond to shifts in its environment does not persist. A delivery system works the same way. The technologies it depends on change. The organizational structures around it shift. The problems it is asked to solve evolve. A system that cannot adapt to these changing conditions gradually becomes less fit for purpose — even if nothing has gone wrong internally.

DVS Improvement Flow is the system’s adaptation mechanism. It keeps the delivery system fit: sensing where friction has emerged, where capabilities are missing, where ways of working no longer match the conditions the system operates in — and making the changes needed to keep the system effective.

This work does not produce a deliverable that gets handed over. It produces a change in how the organization functions. The improvement is realized when the adapted behavior persists — when the system has genuinely changed, not just been intervened on.

Managing this as a flow makes the adaptation work visible, keeps it bounded, and ensures that changes are completed and embedded rather than started and abandoned.

Flow Stages

1. Backlog

Identified improvement needs and opportunities waiting for active attention. An item in the Backlog has been recognized as worth considering but has not yet been analyzed.

Entry: Any identified need to improve how the delivery system functions — working practices, coordination mechanisms, roles and responsibilities, technical capabilities that support delivery.

Exit: A decision to invest time in understanding the improvement need (moves to Analyzing), or a decision not to pursue it.

2. Analyzing

The purpose of Analyzing is to develop a clear shared understanding of what needs to change and why. Work in this stage focuses on the current state, the root cause of the problem or gap, and the desired outcome — not on designing the solution.

Work in this stage:

Clarify what is not working well and why
Define what “better” looks like in observable, behavioral terms
Identify who is affected and who needs to be involved
Assess dependencies and constraints
Scope the improvement to something achievable within a PI

WIP is limited. Improvement work that accumulates in Analyzing creates an illusion of progress without producing change.

Exit: Shared understanding of the problem and desired outcome. Decision to proceed (moves to Committed), or a decision to discard or defer.

3. Committed

The improvement has been analyzed, decided, and placed in the active delivery plan. The approach is agreed. The work is not yet underway — it is waiting for capacity or scheduled into the next PI.

Exit: Capacity becomes available and the improvement work begins (moves to Implementing).

4. Implementing

Active work to make the change. This is where new working practices, structures, roles, or coordination mechanisms are developed and introduced. The work is real — not planning, not piloting, but making the change.

Implementing typically involves the people whose work will change. Changes designed without the involvement of the people who will live them tend not to stick.

Exit: The change has been introduced. The improvement is in use, but not yet confirmed as established (moves to Validating).

5. Validating

The change is in use. Validating confirms that it is working as intended — that the new ways of working are being applied consistently, that the desired outcome is being realized, and that adjustments are made where needed.

This stage is distinct from Implementing. The work here is observation, feedback, and correction — not continued change activity.

Exit: The improvement is operating as intended and is stable in practice (moves to Established), or the approach needs to be revised (returns to Analyzing).

6. Established

The improvement is embedded in the delivery system. New ways of working are operating consistently. Responsibilities and mandates are clear in practice. The capability persists without active oversight — it is part of how the system normally functions.

Established is the done state for improvement work. An improvement that has been implemented but not embedded is not done.

Flow Visualization

Stages with blue border have WIP limits.

The Relationship to DVS Flow

Improvement flow and DVS Flow operate in parallel within the same delivery system. They share the same cadence — both are planned and reviewed within the PI rhythm — but they do not share the same done criteria or the same logic.

DVS Flow is complete when something can be used. DVS Improvement Flow is complete when something has changed in how the system operates.

The two flows are interdependent. A delivery system that only delivers features without investing in its own improvement will degrade over time. A delivery system that invests in improvement but cannot deliver features has lost its purpose.

Flow time, WIP age, and completion rate for improvement work are defined in DVS Flow Metrics.