Release on Demand


Release on Demand is the process that release deployed features gradually or immediately to customers and evaluates the hypothesis from the continuous exploration stage.


There are three major questions to consider in respect to Release on Demand:

  1. When - should we release?
  2. What - elements of the system should be released?
  3. Which - end-users should receive the release?


Release on Demands requires an organisation to develop the following capabilities:

  • Decouple the release from the development cadence
  • Decoupling the release elements from the solution
  • Architechting the solution to support incremental releases



Decouple the Release from the Development cadence


Develop on cadence is the other half of the strategy that allows ARTs and the Solution Trains to operate in a particular pattern and synchronise the efforts of multiple development teams. But when it comes to releasing value, a different set of rules may apply.


Once we have a reliable stream of value through the Continuous Deployment process, the next consideration is when and how to release. The release strategy is decoupled from the development cadence, as shown:



Several release strategies may apply depending on the context and situation:


  • Releasing on the PI cadence
    • Simplest case, since PI Planning, Releasing and I&A have predictable dates
    • IP - Innovation & Planning iterations can be timed, designed and organised to support more extensive release activities
    • IP iterations could include final V&V (Verification & Validation), UAT, and training and release documentation
  • Releasing less frequently
    • May not be feasible / desirable
    • Might constitute critical infrastructure
    • SLA and licence agreements may be prohibitive
    • Potential overhead / disruption of deployment
  • Releasing more frequently
    • For many the goal is to release more frequently
    • Requires DevOps capabilities, efficient delivery pipeline and architecture that supports incremental delivery
  • Release on Demand
    • Above cases are probably over-simplistic
    • Big systems often contain different types of components and sub-systems
    • The most general model is: Release whatever you want and whenever it makes sense, within the governance and business model



Decouple Release elements from the solution


Most solutions, even simple ones, will have multiple release elements, each operating with different release strategies:




For example, this website has multiple release cycles:


  • Ad hoc - Expedited
    • Patch / Security release to a deployed version
  • High Frequency
    • Article updates, readers notified via blog post / mail out
  • Medium Frequency
    • Add new articles whenever significant new content is created
  • Low Frequency
    • Significant changes to the back-end infrastructure / architecture

These separate flows are known as streamlets since they represent full end-to-end flow of value within a value stream. Each streamlet should be managed to deliver value according to its own needs and pace.


Identifying streamlets is critical to Release on Demand, as they allow the different elements of the solution to be release independently in a separate cadence.



Architect the Solution for Incremental Releases


Achieving different release strategies requires solutions to be architected for component (/service based) deployability, releasability and fast recovery.


  • Feature toggles
    • Toggles or switches enable deployment of features into production without making them visible to the end user
    • Help avoid the need for multiple code branches
    • Allow developers to deploy new features to production, but only activate them when the enterprise is ready to consume them
    • After the feature has been release and deemed stable, the toggles are removed to avoid technical debt
  • Canary releases
    • Technique used to reduce the risk of introducing a release into production by slowly rolling out a change to a small subset of users, before rolling it out to the whole user base
    • Allows selective production testing and feature validation without impacting everyone
  • Dark launches
    • Sometimes it's necessary to test new functionality in production before making it available to customers
    • Especially when there is a high uncertainty on how well the system will meet its NFR (Non-Functional Requirements) under a production load

Implementing these strategies might require upgrading infrastructure and architecture, including moving to standard technology stacks, decoupling monolithic applications with micro-services, data preparation and normalisation, third party APIs and data exchange, and logging and reporting tools.



Close the loop on the Feature Hypothesis


After the feature is released, the Benefit Hypothesis needs to be evaluated:

  • Were the intended outcomes achieved?
  • Should a canary release be extended to more customers?
  • Turn off the feature toggles?


The feature is considered Done, once we have an understanding of the production results. However, it might be necessary to extend the functionality (persevere) or pivot (remove the feature) to find a different solution.



Building the Release



Team Increment

  • Each Agile team ensures it produces a working increment for the stories, features and components they are responsible for, by:
    • Completing user stories from their Team Backlog, ensuring each meets its local (story) and DoD (Definition of Done)


System Increment

  • Every two weeks, teams build a system increment, integrated stack of new functionality, representing all the backlog items completed by the ART
  • During the system demo, stakeholders review the system increments and provide feedback


Solution Increment

  • ARTs typically only contribute to part of large solutions
  • Integrated, verified and validated solution increments must satisfy both functional and non-functional requirements
  • Subject of the Solution Demo, which brings all the system increments together into a working system


Release Increment

  • Additional activities might be required when releasing, such as:
    • Final release
    • Validation & Verification
    • Release Notes
    • UAT
    • Documentation
    • Training material
    • Marketing activities
  • These activities, as much as possible, are part of the DoD of the previous increments. However, some will remain as release activities


A Scaled Definition of Done