Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
—Agile Manifesto
The Continuous Delivery Pipeline (also referred to as ‘the pipeline’) represents the workflows, activities, and automation needed to provide a continuous release of value to the end user. The pipeline consists of four elements: Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on Demand, as shown in Figure 1.
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 is possible with the currently used processes. For some software systems, ‘continuous’ means daily releases or even releasing multiple times per day. For others, ‘continuous’ may mean weekly or monthly releases.
For large and complex systems, releasing the solution incrementally avoids taking an ‘all-or-nothing’ approach. Consider a satellite system consisting 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. Other elements, such as the hardware components of the satellite itself, may be released only once per launch cycle.
In a sense, then, continuous delivery means what you need it to mean—as long as the goal is to deliver far more frequently than is happening 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.
The Lean Startup [1] 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), in tandem with big financial commitment up-front, is a poor way to foster innovation. Such an approach assumes and commits too much time, people, and resources 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 validated learning, and for that, we need to apply the steps in the hypothesize–build–measure–learn cycle:
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 needed to complete that epic.
Build an MVP – Based on the hypothesis of the epic, the next step is to implement a Minimum Viable Product (MVP)—that is, 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 is a trailing economic indicator. Instead, teams apply ‘innovation accounting’ [1] and design the systems to provide fast feedback on the leading indicators of future success. These indicators 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 what to do next. Specifically, should they pivot—stop doing that work and start doing something else—or should they 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 when the Weighted Shortest Job First (WSJF) model is used. WSJF also has the unique advantage of ignoring sunk costs on the epic to date, as the job size includes only the work remaining.
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 depicted in Figure 3.
Figure 3. The continuous delivery pipeline is a mechanism for continuous learning and value delivery
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 process is summarized in Figure 4.
This cycle includes four major elements:
Collaboration – Product Management enables and facilitates a continuous and collaborative process that solicits input from a diverse group of stakeholders. These stakeholders include 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—namely, the vision, Roadmap, and Program Backlog. The net result is a set of features in the backlog that 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 and developing, testing, integrating, and finally validating them in a staging environment. Each feature implementation follows the Lean UX cycle [3], 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, as shown in Figure 5.
Since features are too abstract to be coded directly, they must be converted into 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 are compatible with the existing functionality, the overall system must be continually tested as well. Thus, teams apply automated testing and Test-First Development.
Agile teams implement the features and components for which they are responsible. Of course, that isn’t enough to ensure compatibility and overall progress. 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. In the Solution Demo event, the results are made visible to the customer and other stakeholders. To be able to routinely perform solution demos, 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 deploys them into the staging and production environments, where those features are readied for release.
Figure 6 identifies six general practices that can help an organization 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 chapter.
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 the Release on Demand chapter, 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 approach is further facilitated by contemporary release strategies, including techniques such as feature toggles, dark releases, and canary releases [4], all of which are described in the Release on Demand chapter.
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 the following series of states:
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 are 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
[1] Manifesto for Agile Software Development. http://agilemanifesto.org/.
[2] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Random House. Kindle Edition.
[3] Gothelf, Jeff, and Josh Seiden. Lean UX: Designing Great Products with Agile Teams. O’Reilly Media. Kindle Edition.
[4] 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.
