Continuous Delivery Pipeline

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

— Agile Manifesto

Talk to Learning Advisor

Name(Required)
This field is for validation purposes and should be left unchanged.

Continuous Delivery Pipeline

The Continuous Delivery Pipeline (CDP) represents the workflows, activities, and automation needed to guide new functionality from ideation to an on-demand release of value.

Continuous Delivery Pipeline Courses

Search:

Event Venue Date
SAFe® 5 DevOps (SDP) Certification – Remote Course (Central Standard Time Zone) – June 13-14, 2024
  • June 13, 2024 9:00 am
Register
Figure 1 illustrates the pipeline’s four aspects: Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on Demand.
Figure 1. The SAFe Continuous Delivery Pipeline

The Continuous Delivery Pipeline (CDP) 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 CDP (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 CDP allows each ART to deliver new functionality to users far more frequently than traditional processes. For some, continuous may mean daily or even releasing multiple times per day. For others, it may mean weekly or monthly releases—whatever satisfies market demands and the goals of the enterprise.

Legacy practices often cause ARTs to make solution changes in large monolithic chunks. However, this does not usually need to be an all-or-nothing approach. For example, a satellite system comprises a manufactured orbital object, a terrestrial station, and a web farm that feeds the acquired data to end users. Some components may be released daily—perhaps the web farm functionality or satellite software. Other elements, like the hardware components, can only be done once 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 the delivery of solution components in response to frequent market changes.

The Four Aspects of the Continuous Delivery Pipeline

The SAFe CDP 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 use relentless improvement to deliver value to customers. Internal feedback loops often identify process improvements, while external feedback identifies solution improvements. The improvements collectively create synergy in ensuring the enterprise is ‘building the right thing, the right way’ and frequently delivering value to the market. The paragraphs below describe each aspect.

 

  • Continuous Exploration (CE) focuses on creating alignment on what needs to be built. In CE, design thinking ensures the enterprise understands the market problem or customer need and the solution required to meet that need. It starts with a hypothesis of something that will provide value to customers. Ideas are then analyzed and further researched, leading to the understanding and convergence of the requirements for a Minimum Viable Product (MVP) or Minimum Marketable Feature (MMF). These feed the solution space for 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 ART Backlog.
  • Continuous Integration (CI) focuses on taking features from the ART backlog and implementing them. In CI, the application of design thinking tools in the problem space focuses on the refinement of features (for example, 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, 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 ensure they are working correctly. This step makes the features available in production, where the business determines the appropriate time to release them to customers. This aspect allows the organization to respond, rollback, or fix forward when necessary.
  • Release on Demand (RoD) is the ability to make value available to customers together or in a staggered fashion-based on market and business needs. This approach allows the business to release when market timing is optimal and carefully controls the risk associated with each release. Release on demand also encompasses critical pipeline activities that preserve solutions’ stability and enduring value long after release.

 

Although described sequentially, the pipeline isn’t strictly linear. Instead, it’s a learning cycle that allows teams to establish one or more hypotheses, build a solution to test each one, and learn from that work, as Figure 2 illustrates.

Figure 2. The CDP fosters continuous learning and value delivery

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. But too often, they are not fully automated, contain significant delays, and require tedious and error-prone manual intervention. These factors cause organizations to delay releases, increasing their size and scope (“We’ll release when it is big enough”). This approach is the opposite of the SAFe Principle #6, which makes value flow without interruption.

The first step to improving value flow is mapping the current pipeline. Figure 3 illustrates the flow of value through one enterprise’s CDP, focusing initially on new Feature development. Over time, this map would be extended to capture any change to the system, from new Features to maintenance to architectural improvements.

Figure 3. A map of one company’s delivery pipeline

Once the current pipeline has been mapped, metrics can be collected and recorded on the value stream map to understand where delays occur. These metrics enable the ART to 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. For 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 the 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 not to have metrics on specific steps. In this case, the ART can improve the remaining process while metrics are gathered on the variable part.
  • Delay time is the time when no work is happening. Figure 4 shows that the features accepted by the Product Manager are 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 %C&A metric helps identify the steps where poor quality might be occurring and causing longer lead times, resulting in delays in 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 %C&A, 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 steps.

Working ‘Software’ over Comprehensive Documentation

Figure 4. Value stream map with flow metrics

Tracking Continuous Delivery

Continuous delivery is an extensive process. Indeed, it may be the most vital capability of every ART and Solution Train. Product Management and its stakeholders should visualize and track ongoing work, even though a significant portion of the development is automated. The ART Kanban facilitates the flow of Features through the CDP. Work in Process (WIP) limits help improve throughput and identify and address bottlenecks. Figure 7 illustrates a typical ART Kanban, example policies, and WIP limits governing each state.
Figure 7. An example ART Kanban board

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 critical attributes, including the business benefit hypothesis and acceptance criteria.
  • Ready – After analysis, higher-priority features move to the backlog, where they’re ranked.
  • Implementing – At every PI boundary, top features from the ART backlog are pulled into the implementing stage, where they’re developed and integrated into the system baseline.
  • Validating on staging – Features ready for feedback get pulled into this 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 – Features are released once a sufficient amount of value has been created to meet market demands 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.

Enable the Continuous Delivery Pipeline with DevOps

Building, maintaining, and optimizing a continuous delivery pipeline requires specialized skills and tools throughout the entire value stream. Because this type of delivery system calls for the rapid delivery of complex solutions with very short learning loops and high degrees of cross-functional collaboration, DevOps methods are ideally suited to enable it. In other words, continuous delivery pipelines are best implemented with DevOps, as illustrated in Figure 8. © Scaled Agile, Inc. Include this copyright notice with the copied content. Read the FAQs on how to use SAFe content and trademarks here: https://scaledagile.com/about/about-us/permissions-faq/ Explore Training at: https://scaledagile.com/training/calendar/

Individuals and Interactions over Processes and Tools

Deming notes, “If you can’t describe what you are doing as a process, then you don’t know what you are doing. [10]” So, Agile processes in frameworks like Scrum, Kanban, and SAFe matter. However, a process is only a means to an end. When we’re captive to a process that isn’t working, it creates waste and delays. So, favor individuals and interactions, then modify processes accordingly. Tools are valuable but should supplement, rather than replace, face-to-face communication.

Working ‘Software’ over Comprehensive Documentation

Documentation is important and has value. But creating documents to comply with potentially outdated corporate governance models has limited value. As part of a change program, governance, often captured by documentation standards, needs to be updated to reflect the Lean-Agile way of working. Rather than create detailed documentation too early—especially the wrong kind—it’s more valuable to show customers working software, systems, and so on to get their feedback. Therefore, favor measuring progress by evaluating tangible work products. And document only what’s truly needed.

Customer Collaboration over Contract Negotiation

Customers are the ultimate deciders of value, so their close collaboration is essential in pursuing business agility. Contracts are often necessary to convey each party’s rights, responsibilities, and economic concerns—but recognize that contracts can over-regulate what to do and how to do it. They don’t replace regular communication, collaboration, and trust, no matter how well they’re written. Instead, contracts should be win-win propositions. Win-lose contracts usually result in poor economic outcomes and distrust, creating contentious short-term relationships instead of long-term business partnerships. Instead, favor customer collaboration over contract negotiation.

Responding to Change over Following a Plan

Change is a reality in the digital age and essential to achieving agility. The strength of Lean-Agile is in how it embraces change. As the system evolves, so does the understanding of the problem and the solution domain. Business stakeholder knowledge also improves over time, and customer needs evolve as well. Indeed, those changes add value to our system.

Of course, planning is an essential part of Agile. In fact, Agile teams and teams-of-teams plan more often and more continuously than their waterfall counterparts. However, plans must adapt as new learning occurs, new information becomes visible, and the situation changes. Worse, evaluating success by measuring conformance to a plan drives the wrong behaviors (for example, following a plan in the face of evidence that the plan is not working).

Figure 8. DevOps enables the CDP
SAFe’s CALMR approach to DevOps is a mindset that guides continuous value delivery by improving Culture, Automation, Lean Flow, Measurement, and Recovery. DevOps technical skills, practices, and tooling are grouped into practice domains, represented by the model’s inner loops. The two outer loops represent the four aspects of the CDP, each of which has four activities.

Agility is principally about mindset, not practices.

― Jim Highsmith, Agile Project Management: Creating Innovative Products

Contact Us Today

Name(Required)
This field is for validation purposes and should be left unchanged.

Schedule a Consultation

Book directly on my Calendly: calendly.com/vkapila
Name(Required)
This field is for validation purposes and should be left unchanged.

Get a Quote

Book directly on my Calendly: calendly.com/vkapila
Name(Required)
This field is for validation purposes and should be left unchanged.