Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

—Agile Manifesto



Continuous Delivery Pipeline

The Continuous Delivery Pipeline (also referred to as the ‘pipeline’) represents the workflows, activities, and automation needed to shepherd a new piece of functionality all the way from ideation to an on-demand release of value to the end user.

As illustrated in Figure 1, the pipeline consists of four dimensions: Continuous Exploration (CE)Continuous Integration (CI)Continuous Deployment (CD), and Release on Demand, each of which is described in its own article.


Figure 1. The SAFe Continuous Delivery Pipeline

The pipeline is the most significant element of the DevOps and Release on Demand Enterprise competency. Each Agile Release Train(ART) builds and maintains (or shares) a pipeline with the assets and technologies needed to deliver solution value as independently as possible. The first three elements of the pipeline (CE, CI, and CD) work together to support delivery of small batches of new functionality, which are then released in accordance with market demand.


Building and maintaining a Continuous Delivery Pipeline provides each ART with the ability to deliver new functionality to users far more frequently than with current processes. For some, ‘continuous’ may mean daily releases or even releasing multiple times per day. For others, continuous may mean weekly or monthly releases—whatever the market demands.

And while we tend to think of releases as large monolithic chunks, the reality is that it need not translate to an ‘all-or-nothing’ approach. Using a satellite as an example, the elements of the system are comprised of the satellite, the ground station, and a web farm that feeds the acquired satellite data to end users. Some elements may be released daily—perhaps the web farm functionality. Other elements, like the hardware components of the satellite itself, may only be released every launch cycle.

Decoupling the software and the web farm functionality from the physical launch constraints and eliminating the ‘full release’ approach opens up the larger opportunity, which is to deliver the system—in whole or in part—in a way that meets market needs.

Start by Mapping the Current Delivery Pipeline

Of course, successful enterprises already have a delivery pipeline—otherwise, they wouldn’t be able to release any value at all. But they are rarely fast, automated, efficient and continuous. In order to improve the pipeline, and to better understand where to focus the effort, the first step is to map the flow of value through the system. As an example, Figure 2, illustrates the flow of value through one enterprise’s current pipeline.

Figure 2. A map of a company’s delivery pipeline

Three primary metrics [1] are used to measure the flow of value and to identify bottlenecks (Figure 3):

  • Process Time is the time it takes to get work done in one step. As an example, in Figure 3 the ‘Design’ step takes 4 hours.
  • Lead Time is the time it takes from when the work was done in the previous step until it’s done in the current step. This means Lead Time = Wait Time from Last Step + Process Time of current step. In Figure 3, the work waits for 4 hours before the design begins, making the Lead Time 8 hours.
  • Percent Complete and Accurate (%PC&A) represents the percentage of work that the next step can process without needing rework. Often, delays are caused by poor quality in the upstream (prior) steps. The percent complete and accurate metric helps identify the steps where poor quality might be occurring and causing longer lead times, resulting in delays of value delivery. Figure 3 indicates that 20% of the time the work moving from the ‘Design’ step to the ‘Code’ step, needs to be reworked.
Figure 3. Pipeline metrics

Building the Continuous Delivery Pipeline with DevOps

Once the current flow is understood the continuous delivery pipeline can be established. That is what enables the ability to release on demand. The SAFe continuous delivery pipeline model (Figure 1) shows the flow of value through four dimensions: continuous exploration, continuous integration, continuous deployment and release on demand. This represents a triple feedback loop, with value flowing to customers, while feedback and learning flow back to development to inform the decisions on what to build next. The paragraphs below describe each dimension.

  • Continuous Exploration is focused on creating alignment for what needs to be built. It starts with an idea or a hypothesis to create something that will provide value to customers. Ideas are then analyzed and researched, leading to the development of a Minimum Viable Product (MVP). Once the hypothesis is defined, the architecture must be articulated, and Features are defined and prioritized in the Program Backlog. A synchronization point occurs during PI Planning when Agile Release Train (ART) collaborates on what it will build during the next Program Increment (PI).
  • Continuous Integration focuses on building quality into the development process. It starts when work is pulled from CE to be implemented (designed, coded, tested, etc.) by the Agile Teams. Then it’s committed to version control, built and integrated into a full system or solution, and tested end-to-end before being validated on a staging environment.
  • Continuous Deployment takes the changes from the staging environment and deploys them to production. At that point, they’re verified and monitored to make sure they are working properly. This step makes the features available in production, where the business determines the appropriate time to release them to customers. This dimension also allows the organization to respond, rollback, or fix forward when necessary.
  • Release on Demand is the ability to make value available to customers all at once, or in a staggered fashion based on the needs of the market and the business. This dimension provides the opportunity for the business to measure the outcome of its hypothesis and learn what it needs to do next, based on the objective evidence of the customer response to the value released.

While it’s described sequentially, the pipeline doesn’t operate in a strict linear sequence. Rather, it’s a learning cycle that allows teams to establish a number of hypotheses, build a solution to test each hypothesis, and learn from that work, as Figure 4 illustrates.

Figure 4. The Continuous Delivery Pipeline is a mechanism for continuous learning and value delivery

Although a single feature flows through the Value Stream in a sequential manner, the teams work on all dimensions in parallel. That means that ARTs and Solution Trains, throughout every PI and every iteration in the PI, continuously:

  • Explore user value
  • Integrate and demo value
  • Continuously deploy to production
  • Release value whenever the business needs it

Tracking Continuous Delivery

When viewed as a whole, continuous delivery is an extensive process. Indeed, it may be the most important capability of every ART and Solution Train. While it’s automated to the extent possible, it’s important that stakeholders can visualize and track the ongoing work. They need the ability to establish Work in Process (WIP) limits to improve throughput and identify and address bottlenecks. That’s the role of the Program Kanban, as shown in Figure 5.

Figure 5. An example Program Kanban

The Kanban systems consist of a series of states, each of which is summarized below:

  • Funnel– This is the capture state for all new features or enhancement of existing system features.
  • Analyzing– Features that best align with the vision are pulled into the analyzing step for further exploration. Here they’re refined with key attributes, including the business benefit hypothesis and acceptance criteria.
  • Program backlog– After analysis, higher priority features move to the backlog, where they’re prioritized.
  • Implementing– At every Program Increment(PI) boundary, top features from the program backlog are pulled into the implementing stage, where they’re developed and integrated into the system baseline.
  • Validating on staging– Features that are ready for feedback get pulled into the validating on staging step to be integrated with the rest of the system in a staging environment, and then tested and validated.
  • Deploying to production– When capacity is available, features are deployed into the production environment, where they await release.
  • Releasing– When sufficient value meets market opportunity, features are released, and the benefit hypothesis is evaluated.
  • Done– When the hypothesis has been satisfied, no further work on the feature is necessary, and it moves to the done column.

Assessing and Improving the Flow through the Pipeline

As is described in the DevOps and Release on Demand article, the DevOps and Release on Demand health radar shown in Figure 6 helps ARTs and Solution Trains assess their maturity in the 16 sub-dimensions of the continuous delivery pipeline. This radar can be found in the Metrics article.


Figure 6. The SAFe DevOps and Release on Demand health radar


Together, the four dimensions of continuous exploration, continuous integration, continuous deployment, and release on demand provide an integrated Lean and Agile strategy for rapidly accelerating the releases of value to the customer. This strategy can be measured and improved using culture, automation, lean flow, measurement, and recovery aspects of the CALMR approach to DevOps as well as the skills inherent to the four dimensions.


Learn More

[1] Martin, Karen. Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation. McGraw-Hill Education. Kindle Edition.

[2] Kim, Gene. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business WinIT. Revolution Press. Kindle Edition.

[3] Kim, Gene; Humble, Jez; Debois, Patrick; Willis, John. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press. Kindle Edition.


Last update: 10 June 2019