Lean-Agile Delivery System
Updated 30 March 2026
The delivery system is what this reference describes. Every principle, flow, role, and metric in ASP is part of a model of this system — how it is structured, how it operates, and what design choices make it effective.
A delivery system is an IT organization treated as a designed system with a defined purpose: developing and operating IT capabilities for external customers, or for the organization itself. It does not exist in isolation. The delivery system is embedded in a larger organization, which is embedded in a broader environment. Conditions in the environment — market pressures, regulatory requirements, strategic shifts — propagate into the system. The system’s outputs propagate back out, shaping what customers experience and what the organization can do next.
Treating the IT organization as a delivery system is a design choice. It means treating the organization’s structure, processes, and constraints as decisions that can be understood, evaluated, and changed — rather than as fixed conditions to work around.
System Structure
The delivery system operates across two distinct layers with fundamentally different logic. The following diagram shows the system embedded in its organizational and environmental context.
The delivery system is embedded in the organization, which is embedded in the environment. Value flows outward; signals and constraints flow inward.
The portfolio layer governs investment decisions under uncertainty. It determines what is worth funding, in what sequence, and at what scale. The central question is not how to execute — it is what to invest in, given incomplete information about which initiatives will generate value. The dominant problem is economic: how to allocate finite capacity across competing opportunities, and how to recognize when a funded initiative should be continued, redirected, or stopped.
The delivery layer transforms investment into deliverable capability. Once an initiative has been funded and scoped into features, the delivery layer builds, integrates, verifies, and releases. The central question is how to maintain reliable flow of working software at sustainable quality. The dominant problem is operational: limiting work in progress, coordinating across teams, and sustaining technical quality under delivery pressure.
These two layers require different management approaches, different decision frequencies, and different metrics. The portfolio layer works with investment horizons of months to years; the delivery layer works with planning intervals of weeks to months. Applying the portfolio layer’s investment logic to day-to-day delivery decisions — or the delivery layer’s operational logic to investment choices — degrades both.
Value streams are the structural unit that connects the two layers. A value stream is a long-lived group of teams responsible for developing and operating a specific product or system. Investment decisions in the portfolio layer are directed to value streams; features flow through the delivery layer inside them. The value stream has a stable identity, a known capacity, and a continuous delivery cadence — all of which are prerequisites for the portfolio layer to make meaningful investment decisions.
Why Lean-Agile Design
The delivery system described in ASP is built around five design principles. Each reflects a specific, research-grounded rationale.
Flow over push. Work moves through the system based on capacity, not schedule. WIP limits prevent overload. Small batch sizes reduce lead time and make feedback faster. The economic basis is well-established: the relationship between batch size, queue length, and cost of delay is quantifiable. Reducing batch size and limiting WIP is not a process preference — it is the mechanism that keeps flow time predictable and delivery reliable (Reinertsen, 2009).
Continuous learning. The system is designed to learn — from delivery outcomes, from customer feedback, and from measurement of value actually realized. Senge (1990) describes the learning organization as a system that learns faster than its environment changes. In a delivery context, this means feedback loops short enough to inform the next investment decision, not just the next retrospective. A delivery system that does not close the loop between what it produces and what value results will optimize for output rather than outcome.
Economic rationality. Investment decisions are based on the relative value and cost of delay of competing items — not on political negotiation, organizational hierarchy, or annual budget cycles. Reinertsen (2009) provides the formal economic framework. Forsgren, Humble & Kim (2018) provide the empirical grounding: a four-year study of over 23,000 professionals demonstrates that software delivery performance predicts organizational performance — revenue, market share, and productivity. How the delivery system is designed is not a methodology question — it is a business performance question.
Value stream funding. Value streams are funded continuously as operating capacity, not projects episodically. This removes the structural discontinuities that episodic project funding creates: team disbanding at project close, knowledge loss, re-formation overhead, and the misalignment between annual budget cycles and continuous delivery. Kersten (2018) documents the shift from project to product as a structural change in how organizations relate to their delivery capacity.
Capacity visibility. The system’s delivery capacity is known and explicit. Prioritization can therefore answer not only what is most important, but what can realistically be started given what the system can deliver. Without capacity visibility, prioritization produces lists — not decisions.
Lean-Agile vs. Project-Based: Structural Differences
The lean-agile delivery system is not the default organizational form. Most IT organizations were built around a project model that emerged from capital project management — a model designed for one-time construction efforts, not for the continuous development of software products. The structural differences between these two models are consequential.
The project model reflects a coherent set of assumptions: work has a defined start and end; teams are assembled for a specific effort and disbanded when it concludes; funding is allocated per initiative on an annual cycle. These assumptions are reasonable for civil engineering. They misfit software product development, where the product continues after the project ends, where the team’s accumulated knowledge is a primary asset, and where delivery is an ongoing operational state rather than a one-time event.
The table below identifies the structural dimensions where the two models diverge.
| Dimension | Project model | Lean-agile value stream model |
|---|---|---|
| Team structure | Temporary — assembled per project, disbanded at close | Long-lived — stable teams own a value stream continuously |
| Funding | Episodic — annual budget cycles per initiative | Continuous — value streams funded as operating capacity |
| Planning | Point-in-time — detailed upfront, revised under pressure | Cadenced — regular planning intervals with known capacity |
| Delivery continuity | Episodic — delivery ends when the project closes | Continuous — delivery is an ongoing operational state |
| Knowledge retention | Lost at project close — team disbands, context disperses | Retained — teams accumulate domain and system knowledge |
| Learning loops | Post-project review — after delivery and value realization | Continuous — each planning interval creates a structured reflection |
Forsgren, Humble & Kim (2018) document the performance consequences empirically. Elite software delivery organizations — those that deploy frequently, recover quickly from failures, and maintain high quality — are structurally distinct from the majority. The structural choices described in ASP reflect what that distinction looks like in practice.
What ASP Describes
ASP is a model of this system. The portfolio flows describe how investment decisions are made, tracked, and evaluated through the portfolio layer. The DVS and team flows describe how features and stories move through the delivery layer. The role definitions describe the responsibilities the system needs to function. The principles describe the reasoning that underlies the design choices. The metrics describe how the system monitors its own performance.
No part of ASP describes something external to this system. Every document is about one aspect of the same thing.