Develop on Cadence. Release on Demand.

—A SAFe mantra

Release on Demand

Release on Demand is the process by which new functionality is deployed into production and released immediately or incrementally to Customers based on demand.

Release on Demand is the final dimension in the four-part Continuous Delivery Pipeline, preceded by Continuous Exploration (CE), Continuous Integration(CI), and Continuous Deployment(CD) as can be seen in Figure 1.

Figure 1. Release on Demand is the final element of the Continuous Delivery Pipeline

The three dimensions that precede Release on Demand help ensure that new functionality is continuously readied and verified in the production environment. But since tangible development value only occurs when end users are operating the Solution in their environment, releasing that value at the right time is critical for the enterprise to gain the real benefits of agility.

The decision as to when and what to release is a key economic driver that requires careful consideration. For many, continuous delivery is the desired end state. New functionality is released as soon as it is developed. But for others, more often the release is a decoupled, on-demand activity, occurring for specific users, timed for when they need it, or when it makes the most economic sense for the Enterprise.


The core competency article DevOps and Release on Demand describes how the enterprise creates the ability to deliver increasingly valuable solutions to end users with optimal frequency. The second part of this competency, the ability to release on demand raises three questions (which also serve as a reminder of Principle #3, Assume variability and preserve options). These are:

  • When should a release happen?
  • What elements of the system should be released?
  • Which end-users should receive the release?

Keeping these options open for as long as reasonable provides flexibility in delivering value. But only the release can ‘close the loop’ on evaluating the benefit hypothesis proposed during the Continuous Exploration stage of the pipeline. Releasing provides the data needed to decide whether further exploration of an idea is warranted, or if new functionality should be added, or perhaps a different approach is warranted.

The Four Sub-dimensions of Release on Demand

In a manner consistent with the other pipeline dimensions, SAFe describes four sub-dimensions of Release on Demand as can be seen in Figure 2:

  • Release – covers the skills necessary to deliver the solution to end users, all at once or incrementally
  • Stabilize and operate – covers the skills needed to make sure the solution is working well from both a functional and non-functional perspective
  • Measure – covers the skills necessary to quantify whether the newly released functionality provides the intended value
  • Learn – encompasses the skills needed to decide what should be done with the information gathered and prepare for the next loop through the continuous delivery pipeline with new hypotheses
Figure 2. Four sub-dimensions of Release on Demand

Release Value to Customers

When the Solution is in production and has been verified for proper operability, the time has come to make it available to Customers. This is a crucial business decision, as releasing value too early or too late can have severe economic repercussions.  This is the manual gate. Once developers committed code to source control, everything can be automated, up to this point. Changes might be flowing through the pipeline through CI and CD, and they could even be smaller than stories, but as they approach release they need to be aggregated back up to become completed Minimal Marketable Features (MMFs), which are the smallest items that bring value to Customers. Now, in collaboration with stakeholders, Product Management must make the decision to release what to who and when.

Four skills contribute to the ability to release:

  • Dark launches – This provides the ability to deploy to a production environment without releasing the functionality to end users.
  • Feature toggles -This is a technique to facilitate dark launches by implementing toggles in the code, which enables switching between old and new functionality.
  • Canary releases – These provide a mechanism for releasing the solution to a specific Customer segment and measuring the results, before expanding and releasing to more customers.
  • Decouple release elements – Releasing on demand raises a question and an opportunity: Is a ‘release’ a monolithic, all-or-nothing process? If so, the release strategy would be limited. In order to release anything, you would have to release everything. Fortunately, that’s not the case. In fact, even simple solutions will have multiple release elements, each operating with different release strategies, as Figure 3 illustrates.
    Figure 3. Decouple release element from the Solution

    For example, the SAFe website that’s hosting this article has multiple, and somewhat independent release cycles

    • We can make a fix to a deployed version or address a security issue at any time (ad hoc, but expedited class of service)
    • We can update any article at any time and simply notify readers via blog post (high frequency)
    • We can add new articles to the Advanced Topics section whenever significant new content is available (medium frequency).
    • But making major revisions to the framework is only done periodically, based on new content, new ways to render the Big Picture, and most importantly, only when the market is ready for a new release of the full Framework (low frequency)

    We call these separate flows “value streamlets”, as they represent a full, end-to-end flow of value within a Value Stream. Each streamlet can and should be managed to deliver value according to its own needs and pace. Identifying streamlets is critical to enable release on demand, as they allow the different elements of the solution to be released independently in a separate cadence. They also provide how clues as to how organize teams and ARTs so that they can independently Release on Demand.

Stabilize and Operate

The changes to the solution have been verified after they were deployed, but once Customers have access to them new problems might arise. These new problems not only may be due to the increase in usage, but also due to unexpected usage patterns. As incidents and security threats are discovered, they must be resolved quickly and within agreed to Service Level Agreements (SLAs). Four main skills help operate the solution:

  • Cross-team collaboration – A mindset of cooperation across the Value Stream to identify and solve problems as they arise is crucial. This involves building Agile Release Trains that can operate the solution, as well as develop it.
  • Failover/disaster recovery – Failures will occur. It is important to develop a failover mechanism to allow service to resume quickly, or even avoid service interruption. Disaster recovery must be planned, architected into the service, and practiced.
  • Continuous security monitoring – Security as code and penetration testing focus on preventing known vulnerabilities from getting to production. But it is also important to test services continuously for newly discovered and reported vulnerabilities and to detect intrusions and attacks on services and infrastructure.
  • Architect for operations – Operational needs must be considered. Build telemetry and logging capabilities into every application and into the solution as a whole. Allow services to be downgraded or even removed in times of high loads or in response to incidents. Build capabilities for fast recovery and for fix-forward.
  • Monitor nonfunctional requirements (NFRs) – System attributes such as reliability, performance, maintainability, scalability, and usability must be continuously monitored to avoid service disruptions.

Measure the Business Value

The first sub-dimension in the pipeline is hypothesize—and as value is released to Customers it is time to use the application telemetry to measure the hypothesis and the business value delivered. Two skills support this effort:

  • Innovation Accounting – Evaluating hypothesis requires different metrics than those used to measure end-state working solutions. Innovation Accounting focuses on how to measure the intermediate and predictive business outcomes of the hypothesis both during initial incremental solution development and during evaluation of the Minimal Viable Product (MVP). (Read more in the Innovation Accounting)
  • Application telemetry – Application telemetry is the primary mechanism by which usage data could be tracked and measured against the hypothesis.

Learn and React

The information gathered during the measure sub-dimension needs to be analyzed and then a decision made on what to do next, pivot or persevere—remove or keep developing. This is also where learning about the process come in to effect and the information on how value flowed must be used to improve the Continuous Delivery Pipeline. To accomplish this, three skills are needed:

  • Lean startup thinking – If hypotheses and MVPs are evaluated, and the decision is whether the hypotheses have been proved or refuted, should the efforts continue in the current direction, should work stop, or should new hypotheses be formed to evaluate different approaches to the same strategy.
  • Value stream mapping – A key tool to improve the flow of value across the pipeline is value stream mapping. This tool (explained in the Continuous Delivery Pipeline article) provides the visibility needed to identify bottlenecks and problem areas to flow, as well as design a future state and create Enablers to improve the pipeline.
  • Relentless improvement – The flow of work can always be improved. This mindset is part of the SAFe House of Lean and is crucial to achieving results.

When features are in the hands-on Customers, the value is finally realized. When this value is measured, knowledge informs continuous exploration efforts that are ongoing, starting the cycle anew. This is the end of the pipeline for one feature and at the same time the beginning for another, the continuous delivery pipeline drives new value to users and new learning to the organization all the time.

Release Governance

Release governance is the process of planning, managing, and governing solution releases, which helps guide the value stream toward the business goals. In some enterprises, especially those with significant regulatory and compliance criteria, this is a centralized, portfolio-level team or function (Release Management is a common term) that assures releases meet all the relevant business criteria.

In other circumstances, ART and Solution Train leadership and stakeholders from development operations, quality, sales, and other stakeholders take part in the release management and governance responsibilities.

In either case, the release governance facilitates the activities needed to help internal and external stakeholders receive and deploy the new solution. It also ensures that the most critical governance quality elements are appropriately addressed before deployment—particularly internal and external security, regulatory, and other compliance guidelines.

Release planning is part of the PI planning process. But that’s the easy part; the hard part is coordinating the implementation of all the capabilities and features over multiple iterations within a release. This is especially true when new issues, roadblocks, dependencies, and gaps in Vision and backlogs are uncovered. Due to these challenges, the scope of each release must be continually managed, revalidated, and communicated. Primary considerations include:

  • Ensuring that the organization’s release governance is understood and adhered
  • Communicating release status to external stakeholders
  • Ensuring that an appropriate deployment plan is in place
  • Coordinating with marketing and with Product and Solution Management on internal and external communications
  • Validating that the solution meets relevant solution quality and Compliance criteria
  • Participating in Inspect and Adapt (I&A) to improve the release process, value stream productivity, and solution quality
  • Providing final authorization for the release
  • Acting as a liaison with Lean Portfolio Management (LPM), as appropriate
  • Participating in, and overseeing the final release activities

Many enterprises hold release governance meetings weekly to address the following questions:

  • Is the vision still understood, and are the trains and teams aligned for that purpose?
  • Does everyone understand what they are building and is it aligned with the understanding of the purpose of the Value Stream and current Strategic Themes?
  • Are the trains tracking to the scheduled release dates?
  • Is the appropriate quality built-in to the solution?
  • What impediments must be addressed to facilitate progress?

This weekly meeting provides senior management with regular visibility into the release progress. It’s also the place to approve any scope, timing, people or resource adjustments necessary to assure the release. In a more continuous delivery environment, the participants closely monitor the release section of the Program Kanban, making sure items are released when needed to the right audiences, managing dark and canary releases, verifying that hypotheses are evaluated, and that feature toggles are removed after production verification.

Learn More

[1] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Random House, Inc.

[2] Womack, Jim. Gemba Walks Expanded 2nd Edition. Lean Enterprise Institute, Inc.

[3] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series). Pearson Education.


[5] Gothelf, Jeff and Josh Seiden. Lean UX: Designing Great Products with Agile Teams. O’Reilly Media.


Last update: 3 October 2018