Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
—Agile Manifesto
Continuous Delivery Pipeline
Value Stream Mapping
As illustrated in Figure 1, the pipeline consists of four aspects: Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on Demand, each of which is described in its own article.
The pipeline is a significant element of the Agile Product Delivery 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 the delivery of small batches of new functionality, which are then released to fulfill market demand.
Details
Building and maintaining a Continuous Delivery Pipeline provides each ART with the ability to deliver new functionality to users far more frequently than with traditional 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 satisfies market demands and the goals of the enterprise.
Traditional practices tend to perceive releases as large monolithic chunks. However, the reality is that releasing value 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 web farm functionality from the physical launch eliminates the need for a monolithic release. It also increases Business Agility by allowing components of the solution to be delivered in response to frequent changes in market need.
The Four Aspects of the Continuous Delivery Pipeline
The SAFe continuous delivery pipeline contains four aspects: continuous exploration, continuous integration, continuous deployment, and release on demand. The CDP enables organizations to map their current pipeline into a new structure and then use relentless improvement to deliver value to customers. Feedback loops that exist internally within and between the aspects, and externally between the customers and the enterprise, fuel improvements. Internal feedback loops often center on process improvements, while external feedback often centers on solution improvements. Collectively, the improvements create synergy in ensuring the enterprise is ‘building the right thing, the right way’ and delivering value to the market frequently. The paragraphs below describe each aspect.
- Continuous Exploration (CE) focuses on creating alignment on what needs to be built. In CE, design thinking is used to ensure the enterprise understands the market problem / customer need and the solution required to meet that need. It starts with an idea or a hypothesis of something that will provide value to customers, typically in response to customer feedback or market research. Ideas are then analyzed and further researched, leading to the understanding and convergence of what is needed as either a Minimum Viable Product (MVP) or Minimum Marketable Feature (MMF). These feed the solution space of exploring how existing architectures and solutions can, or should, be modified. Finally, convergence occurs by understanding which Capabilities and Features, if implemented, are likely to meet customer and market needs. Collectively, these are defined and prioritized in the Program Backlog.
- Continuous Integration (CI) focuses on taking features from the Program backlog and implementing them. In CI, the application of design thinking tools in the problem space focuses on refinement of features (e.g., designing a user story map), which may motivate more research and the use of solution space tools (such as user feedback on a paper prototype). After specific features are clearly understood, Agile Teams implement them. Completed work is committed to version control, built and integrated into a full system or solution, and tested end-to-end before being validated in a staging environment.
- Continuous Deployment (CD) 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 aspect also allows the organization to respond, rollback, or fix forward when necessary.
- Release on Demand (RoD) is the ability to make value available to customers all at once, or in a staggered fashion based on market and business needs. This provides the business the opportunity to release when market timing is optimal and carefully control the amount of risk associated with each release. Release on Demand also encompasses critical pipeline activities that preserve the stability and ongoing value of solutions long after release.
Although it is described sequentially, the pipeline isn’t strictly linear. Rather, it’s a learning cycle that allows teams to establish one or more hypotheses, build a solution to test each hypothesis, and learn from that work, as Figure 2 illustrates.
Although a single feature flows through the Value Stream sequentially, the teams work through all aspects 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
Start by Mapping the Current Workflow
Successful enterprises already have a delivery pipeline—otherwise, they wouldn’t be able to release any value at all. But too often they are not automated, contain significant delays, and require tedious and error-prone human intervention. This, in turn, causes organizations to delay releases, increasing their size and scope (“We’ll release when it is big enough”). This is opposite of the SAFe Principle #6, which promotes limiting Work in Process (WIP) and reducing batch size.
The first step to improving value flow is mapping the current pipeline. Figure 3 illustrates the flow of value through one enterprise’s current pipeline, focusing initially on new Feature development. Over time, this would be extended to capture any change to the system, from new Features to maintenance to architectural improvements.
Once the current pipeline has been mapped, metrics can be added to measure the flow of value, to understand delays and identify opportunities for improvement (such as eliminating delays or reducing rework). Four primary metrics [1] are used (Figure 4):
- Process Time is the time it takes to get work done in one step. As an example, in Figure 4, the ‘Design’ step takes four 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. In other words, Lead Time = Delay Time from Last Step + Process Time of the current step. In Figure 4, the lead time from creating ideas to defining them is variable. It is common when first mapping systems to not have clear metrics on certain steps. In this case, the remaining part of the process can be improved while metrics are gathered on the variable part.
- Delay time is the time when no work is happening. Continuing with Figure 4, the work accepted by the Product Manager is delayed a staggering 696 hours before being deployed to staging. Understanding and eliminating unnecessary delays is critical to improving the flow of value.
- Percent Complete and Accurate (%C&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 4 indicates that 20% of the time the work moving from the ‘Design’ step to the ‘Code’ step, needs to be reworked. Improving the %C&A metric is also essential to improving the flow of value. The %C&A of a single step is extended to rolled percent complete and accurate, a measure that captures the likelihood that an item will pass through the entire workflow without rework. With a cumulative rolled %C&A of 35%, this workflow is reworking more than half of its items.
Align the Current Workflow to the Continuous Delivery Pipeline
Once the current flow is understood, it can be mapped into the SAFe Continuous Delivery Pipeline. Mapping helps the organization adopt a common mental model and provides an efficient means to communicate changes and improvements. Figure 5 removes the labels of “Continuous” because at this stage the process is unlikely to resemble an automated pipeline.
Identify Opportunities for Improvement
Teams look for the opportunity to improve the efficiency of each step, consequently reducing the total lead time. This includes addressing process time, as well as the quality (percent complete and accurate) of each step. The higher that number, the less rework is required, and the faster the work moves through the system.
As shown in Figure 6, the delay time (time between steps) is often the most significant initial factor. Delay time represents handoffs, waiting, and other non-value-added wastes. This process has two considerable delays and a significant amount of rework in the first step of the deployment process. Reducing delays is typically the fastest and easiest way to lower the total lead time. Another high priority area to improve is any step with low %C&A metrics, as reducing rework enables the ART to focus on creating value (e.g., for a software solution, instead of fixing bugs the team can focus on new features). Subsequent opportunities for improvement focus on reducing batch size and applying the DevOps practices identified in each of the specific articles describing the continuous delivery pipeline.
Tracking Continuous Delivery
When viewed as a whole, continuous delivery is an extensive process. Indeed, it may be the most vital capability of every ART and Solution Train. It’s important that stakeholders can visualize and track the ongoing work, even though a significant portion of it is automated. 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 7.
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 ranked.
- 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.
Enabling the Continuous Delivery Pipeline with DevOps
Building, maintaining, and optimizing a continuous delivery pipeline requires specialized skills and tooling throughout the entire value stream. Because this type of delivery system calls for rapid delivery of complex solutions with very short learning loops and high degrees of cross-functional collaboration, DevOps methods are perfectly suited to enabling it. In other words, continuous delivery pipelines are best implemented with DevOps, as illustrated in Figure 8.
The outer two rings represent the continuous delivery pipeline, with its four aspects and 16 activities wrapped into a closed learning loop. The inner rings represent DevOps practice domains that ‘power’ the CDP. Each domain contains specific practices and tools that members of the value stream use to perform CDP activities. SAFe’s CALMR approach to DevOps, shown at the center of the figure, is the shared mindset that guides behavior and decision making throughout the entire system.
Additionally, SAFe’s DevOps Health Radar allows ARTs to quickly assess the performance of their delivery pipelines and identify specific DevOps practices that can be applied to optimize them.
See the DevOps article series for more detailed guidance on how to implement and optimize continuous delivery pipelines.
Learn More
[1] Martin, Karen. Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation. McGraw-Hill Education, 2013. [2] Kim, Gene. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. IT Revolution Press, 2013. [3] Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press, 2016.
Last update: 17 February 2023
