Develop on Cadence. Release on Demand.

—A SAFe mantra

Release on Demand

Release on Demand is the process that deploys new functionality into production and releases it immediately or incrementally to customers based on demand.

Release on Demand is the final aspect in the four-part Continuous Delivery Pipeline of Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment, and Release on Demand (Figure 1).

The three aspects 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 crucial economic driver that requires careful consideration. For many, continuous delivery is the desired end state, allowing new functionality to be released as soon as it is developed. But 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.

Details

The Agile Product Delivery competency article describes how the Develop on Cadence; Release on Demand competency 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 for Product and Solution Management. These are:

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

A customer-centric mindset guides how Product and Solution Management answers these questions:

• Market rhythms and market events should inform releases and align to customer time frames
• Release elements, such as new Features or the entire system, should be targeted to specific customers segments

Decoupling releases provides additional benefits that promote business agility, especially for value streams serving external customers:

• Product marketing can target promotional activities to specific audiences
• Sales activities can be structured with greater confidence in the timing and functionality of the solution

The Four Activities of Release on Demand

As illustrated in Figure 2, SAFe describes four practices associated Release on Demand:

• Release describes the practices necessary to deliver the solution to end users, all at once or incrementally
• Stabilize and operate describes the practices needed to make sure the solution is working well from a functional and non-functional perspective
• Measure describes the practices necessary to quantify whether the newly-released functionality provides the intended value
• Learn describes the practices needed to decide what should be done with the information gathered and prepare for the next loop through the continuous delivery pipeline

Release Value to Customers

When the Solution is in production and has been verified as operable, 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 negative economic repercussions. Product management, in collaboration with other stakeholders, establishes policies that govern this process, ranging from automatically allowing qualified code to be released to customers or establishing a more formal review process with a manual gate. The more complex the system, the more likely there will be a manual gate to determine the answers to the critical questions presented earlier (what to release, to whom, and when).

Four practices 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.
• Decoupled release elements – This technique identifies specific release elements, each of which can be released independently. Even simple solutions will have multiple release elements, each operating with different release strategies, as Figure 3 illustrates.

 

For example, the SAFe website that’s hosting this article has multiple, and somewhat independent release cycles. Scaled Agile can:

• Fix a security issue in our hosting infrastructure at any time (an ad hoc, but expedited, class of service)
• Update any article at any time and simply notify readers via a blog post (high frequency)
• Add new articles to the Advanced Topics section whenever significant new content is available (medium frequency)
• Create major revisions to the framework, including updates to the Big Picture, at a frequency that balances the ability of our customers to absorb new versions of the framework and our own development efforts (low frequency)

These separate flows – ‘value streamlets’ – continue to represent a full, end-to-end flow of value within a Value Stream, each of which is 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 insights on the organization of 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. Incidents and security threats must be resolved quickly and within agreed to Service Level Agreements (SLAs). Four practices 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’s vital 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’s 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. High loads, security attacks, and responding to incidents motivate a range of options from downgrading or removing services to adding capacity. Telemetry and logging capabilities enable organizations to better understand and further tune their architecture to meet actual usage patterns.
• Monitor nonfunctional requirements (NFRs) – To avoid service disruptions, system attributes such as reliability, performance, maintainability, scalability, and usability must be continuously monitored.

Measure the Business Value

The first activity of continuous exploration is to hypothesize—and as value is released to customers, it’s time to use the application telemetry to measure the hypothesis and the business value delivered. Two practices support this effort:

• Application telemetry – Application telemetry is the primary mechanism used to track and measure data usage against the hypothesis.
• Innovation Accounting – Evaluating a 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 during initial incremental solution development and evaluation of the Minimum Viable Product (MVP). (Read more in the Innovation Accounting article.)

Learn and React

The information gathered from release is used to close the loop in the continuous delivery pipeline. Product management will use these data to make a choices about Epics, determining if the Epic hypothesis was proven true, if a pivot is warranted, or if the Epic should be stopped and development effort applied elsewhere. This is also where learning about the process comes into effect, and the information on how value flowed must be used to improve the continuous delivery pipeline. Three practices help accomplish this:

• Lean startup thinking – As MVPs are evaluated, hypothesis are proved or refuted. When hypotheses are refuted, the organization must decide if efforts should continue, should work stop, or should the new Epics with new hypotheses be formed to evaluate different approaches to the same strategy?
• Value stream mapping – An essential tool to improve the flow of value across the pipeline is value stream mapping. This tool 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 the ongoing exploration efforts, starting the cycle anew. For one feature, this is the end of the pipeline. For another, however, it’s the beginning, as the continuous delivery process drives new value to users and new learning to the organization continually.

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 SAFe 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 assume some release management and governance responsibilities.

In either case, 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 events on a regular cadence 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 event 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.

Enabling Release on Demand with DevOps

This aspect of the continuous delivery pipeline reveals the cumulative value of all upstream efforts, closing the learning loop that began with continuous exploration. All activities must be quick, low-risk, aligned to business outcomes, and optimized for fast, accurate feedback. DevOps practices and tooling enable the responsiveness that is so critical in this ‘last mile’ of the delivery pipeline.

As depicted in Figure 4, release on demand is enabled by SAFe’s CALMR approach to DevOps (center) as well as several practice domains (inner rings). Each of the four activities (in green) is a collaborative effort that draws upon DevOps expertise from multiple domains to maximize business value and validated learning.

Releasing, for example, requires instantaneous activation of deployed solutions using infrastructure configurations stored in version control, proactive monitoring that informs operations teams of the health, security, and value of those solutions, and fast recovery from production issues in accordance with value stream service level agreements.

All four release on demand activities are enabled by DevOps, though with different combinations of technical practices and tooling. For more guidance on DevOps and how it enables the continuous delivery pipeline, see the DevOps article series.

---

Learn More

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

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

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

[4] http://www.innovationgames.com

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

 

Last update: 27 September 2021