Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Continuous Delivery Pipeline
The Continuous Delivery (CD) Pipeline (also referred to as ‘pipeline’) represents the workflows, activities, and automation needed to provide a continuous release of value to the end user.
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 work together to support delivery of small batches of new functionality, which are then released in accordance with market demand.
The Continuous Delivery Pipeline represents the ability to deliver new functionality to users far more frequently than current processes are able to. For some software systems, ‘continuous’ means daily releases or even releasing multiple times per day. For others, continuous may mean weekly or monthly.
For large and complex systems, releasing the solution avoid taking an ‘all-or-nothing’ approach. Consider a satellite system comprised of the satellite, the ground station, and a web farm to feed the acquired satellite data to end users. Some elements may be released continuously—perhaps the web farm functionality. Others, like the hardware components of the satellite itself, may only be released every launch cycle.
So, in a sense, continuous delivery means what you need it to mean—as long as the goal is to deliver far more frequently than now. In our satellite example, the more capability that gets moved to software, the more continuous the delivery can become, as those elements can then be decoupled from physical launch constraints. In all cases, the goal should be clear: more frequent delivery of value to the end user.
Fostering Innovation with the Lean Startup Cycle
The Lean Startup  movement has captured the imagination of business and technical leaders around the world. Inspired in part by the emergence of Agile methods, Lean Startup advocates recognized that ‘Big Design Up-front’ (BDUF), along with big-up-front financial commitment, is a poor way to foster innovation. It assumes and commits too much before having any validated learning.
Instead, the Lean Startup movement embraces the highly iterative ‘hypothesize-build-measure-learn’ cycle, which fits quite naturally into SAFe. Specifically, we can apply this model to any Epic, whether it arises at the Portfolio, Large Solution, or Program Level. No matter the source, the scope of an epic calls for a sensible and iterative approach to investment and implementation, as reflected in Figure 2.
As Figure 2 implies, approved Epics deserve additional investment—but not a fully committed investment up-front. After all, the work up to that point has been analytical and exploratory. The proof is in the pudding, and for that, we need to apply the hypothesize-build-measure-learn cycle, including the steps below:
- Hypothesize – Each epic has a Lean business case, which includes the hypothesis that describes the assumptions and potential measures that can be used to assess whether an epic will deliver business value commensurate with the investment.
- Build an MVP – Based on the hypothesis of the epic, the next step is to implement a Minimum Viable Product (MVP)—the minimum effort necessary to sufficiently validate or invalidate the hypothesis. In SAFe, this translates to the minimum Feature set required to deliver some holistic, but minimal, solution.
- Evaluate the MVP – Once the feature set is implemented, teams evaluate the MVP against the hypothesis. However, this evaluation is not based on Return on Investment (ROI), as that’s a trailing economic indicator. Instead, teams apply ‘innovation accounting,’  and design the systems to provide fast feedback on the leading indicators of future success. These might include usage statistics, system performance, or anything else that would be a useful metric.
- Pivot or persevere – With the objective evidence in hand, teams and stakeholders can decide: pivot—stop doing that work and start doing something else; persevere—define features to further develop and refine the innovation.
- Implement additional features – Choosing to persevere means work continues until new epic-inspired features that hit the backlog can’t compete with other features. This will occur naturally via ‘Weighted Shortest Job First’(WSJF). WSJF also has the unique advantage of ignoring sunk costs on the epic to date, as the job size includes only the work remaining.
The Continuous Delivery Pipeline Learning Cycle
In short, 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 3 illustrates.
Now, let’s move on to summarizing the activities of continuous exploration, continuous integration, continuous deployment, and release on demand.
Continuous exploration is the process of constantly exploring the market and user needs, and defining a Vision and a set of features that address them. This is summarized in Figure 4 and the paragraphs below.
The four major elements of this cycle are:
- Collaboration – Product Management enables and facilitates a continuous and collaborative process that solicits input from a diverse group of stakeholders. This includes Customers, Agile Teams, Product Owners, Business Owners, portfolio epics, and System and Solution Architects/Engineering.
- Research – In addition to the direct input, Product Management uses a variety of research activities and techniques to help establish the vision. These include customer visits, Gemba walks, active requirements, elicitation techniques, trade studies, and original and applied market research.
- Synthesize – Product Management synthesizes their findings into the key SAFe artifacts of vision, Roadmap, and Program Backlog. The net result is a set of features that are in the backlog and are ready for implementation.
- Implementation – Now the work of implementation begins. At the strategic level, work follows the Lean Startup Cycle, which consists of an initial MVP feature set, followed by additional features until the higher priorities of other work take over.
The next cycle in the pipeline is continuous integration, the process of taking features from the program backlog, developing, testing, integrating, and finally, validating them on a staging environment. Each feature implementation follows the Lean UX cycle,  producing an initial ‘Minimum Marketable Feature‘ (MMF), followed by whatever extensions deliver appropriate and additional economic value.
Continuous integration often requires a three-tier approach: story integration, system integration, and solution integration.
Since features are too abstract to be coded directly, they must be converted to Stories during PI Planning. Each story is defined, coded, tested, and integrated into the baseline. Team members integrate their individual work frequently and apply automated continuous integration environments. To ensure that the new stories work compatibly with all the existing functionality, the system must be continually tested as well. So, teams apply automated testing and Test-First Development.
Agile teams implement the features and components they’re responsible for. But of course, that isn’t enough. With the support of the System Team, the work of all teams on the ART must be integrated frequently to assure that the system is evolving as anticipated. At the all-important System Demo, this small batch of work is evaluated objectively.
Finally, the largest solutions require an additional level of integration, as the work from all ARTs and Suppliers must be integrated together. The Solution Demo event is where the results are made visible to the customer and other stakeholders. In order to be able to do this routinely, ARTs and Solution Trains invest in solution-level integration, testing, and supporting infrastructure. Even then, the extent of integration and testing may be less than 100 percent and may need to vary across multiple early integration points.
Continuous deployment is the process that takes features that have passed through continuous exploration and continuous integration, and then deploys them into the staging and production environments, readied for release.
Figure 6 provides six general practices to help implement a continuous deployment environment and process.
The labels for each of these practices are somewhat self-explanatory. Each is described in further detail in the Continuous Deployment article.
Release on Demand
Release on Demand is the process that releases deployed features gradually or immediately to customers and evaluates the hypothesis from the continuous exploration stage. But as we describe in that article, continuously releasing is not always automatic. Nor is it an ‘all-or-nothing’ proposition, as Figure 7 illustrates.
Instead, elements of the system are released as they become available and as the market demands. This is further facilitated by contemporary release strategies, including techniques such as feature toggles, dark releases, and canary releases,  all of which are described in the ‘release on demand‘ article.
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. And 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 8.
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, so it moves to the done column.
Together, 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.
Learn More Agile Manifesto.org  Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Random House, Inc. Kindle Edition.  Gothelf, Jeff and Josh Seiden. Lean UX: Designing Great Products with Agile Teams. O’Reilly Media. Kindle Edition.  Kim, Gene and Jez Humble, Patrick Debois, John Willis. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press. Kindle Edition.
Last update: 12 September, 2017