Deliver software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
—Agile Manifesto

There are really three parts to the creative process. First there is inspiration, then there is the execution, and finally there is the release.
—Eddie Van Halen

Release Abstract

The goal of Lean development is frequent delivery of valuable, working, and fully tested increments of the Solution. This is accomplished via a stream of Releases of value, each of which has been validated and approved for final efficacy of use, accompanied by the documentation necessary to ensure successful application. Accomplishing this requires leaner software and engineering practices, as well as a more continuous process of verification and validation. In addition, there are typically some final, pre-shipment validation, documentation, and support activities necessary for successful release into production, or directly into the Customer’s world.


Releasing Value More Frequently

Every Release delivers more value to the Customer. Also, some ideas, assumptions, and aspects of the Solution cannot be fully validated until and unless they are released into the customer’s environment. In those cases, truly meaningful feedback about efficacy, deployability, and usability can only be partially assessed in the development environment. For that reason, releasing more frequently is one of the goals of the Lean-Agile Enterprise.

For many, releasing is a homogenous thing. A widget may be released to manufacturing or into the customer’s environment in a single event. However, complex solutions are, by definition, more complex, and in these cases different elements of the system may be released at different times. Optimizing for overall value delivery means that each element might need to have its own delivery rhythm.

Take, for example, the Baja Ride. Software updates to the player portal can perhaps be delivered every two weeks, every day, or even on demand, and the Customer and users can thereby receive the benefit of fast, incremental delivery. Perhaps the vehicle control system can receive occasional over-the-air software updates, but it could easily require some necessary off-line, end-user validation before deployment, so some batching and testing is required. Releasing that subsystem might be on a cadence or it might be ad hoc, based on context, problems, and opportunities, to improve reliability or some aspect of the ride experience. Finally, a newer motion base, complete with updated firmware and hardware, might warrant being released and installed on the vehicle only annually. Figure 1 illustrates this example.

Figure 1. Different elements of the solution may have different delivery rhythms
Figure 1. Different elements of the solution may have different delivery rhythms


Develop on Cadence, Release Any Time

Given these opportunities and constraints, releasing does not have to be aligned with the development cadence. Develop on Cadence, Release Any Time supports the goals of synchronization, alignment, management of variability, and predictability of development velocity. Delivery can happen whenever the business needs it. That being said, however, many enterprises find it convenient to align delivery of some or all aspects of the solution to a Program Increment (PI) boundary. In these cases the development rhythm and delivery rhythm can be the same, and there can be many associated conveniences.

Building the Release

Building large-scale systems that are ready for release and fit for use is a process most easily considered in stages, as Figure 2 illustrates.

Figure 2. Building a releasable solution
Figure 2. Building a releasable solution

Team Increment

The first, and hopefully continuous, step in this process is each Agile Team on the Agile Release Train (ART) focusing on ensuring that they produce a working increment for the Stories and components they are responsible for. They do this by:

  • Completing user stories from their Team Backlog, assuring that each meets its story (local) Definition of Done
  • Applying Continuous Integration practices with test automation whenever feasible to monitor and ensure progress

System Increment

Every two weeks, teams build a system increment, an integrated stack of new functionality, which is the sum of all the team backlog items completed by all release train teams, during the current and all previous Iterations. Each system increment is the subject of the System Demo. In this way, one story at a time, new Features are added to the system incrementally, typically a few per program increment.

For those features that are completed within the increment, feature acceptance criteria must be met. Some features, however, can be still in progress, so the current increment may include some, but not all, of their functionality. To make sure that all the functionality is consistent, the train performs verification and validation of key scenarios and nonfunctional aspects, usually with the help of the System Team.

Each system increment is a result of the work of multiple teams and, as such, needs to be integrated, as indicated above. However, in some cases full integration of all program assets may represent a high transaction cost (assembly, configuration, testing, etc.), especially when the solution Capabilities involve hardware components. In such cases it is important to find the right balance of effort and frequency. While the Definition of Done for a system increment can be relaxed at times, to allow for faster feedback without full integration, this should not be an excuse to abandon the practice of frequent integration and testing. The system increment is the primary measure of progress for ARTs (each a learning Milestone), and not having increments at a certain frequency simply means not knowing where the team is with respect to the system development.

At the PI boundary, each Agile Release Train does a final system demo during the Inspect and Adapt workshop that shows the features developed throughout the entire PI.

Solution Increment

In a multi-ART Value Stream, ARTs typically build only a part of the solution, whether it’s a set of subsystems, some solution capabilities, or a mix thereof. For that reason, the real progress of the solution development effort can only be objectively evaluated based on the solution increment that comprises all the capabilities, collaboratively delivered by ARTs, integrated, verified, and validated, with both the functional and Nonfunctional Requirements (NFRs) satisfied. This solution increment is the subject of the all-important Solution Demo, which brings all the increments together into a working system.

The full system integration process will likely require assistance by Program and Value Stream Level System Teams. Indeed, that is the major reason why they exist. SAFe suggests that this activity is less frequent than the others described in this article, with an emphasis on the PI boundary. On large systems, especially those with mixed hardware and software components, the transaction costs may be fairly high, thus the implication of a lower frequency.

Sometimes much of this work is performed during the Innovation and Planning (IP) Iteration, where the availability of personnel, Supplier subsystems and components, special skills and equipment, and other resources can be applied to that significant task. But that is not always the case. If the enterprise wants to acquire a better understanding of progress within the PI, it may choose to produce solution increments at a more frequent rate. In this case, the solution-level integration effort may be dispersed across multiple iterations within the PI, as opposed to all being encapsulated in the IP iteration. In that case, the system demo is a validation of the progress up to that point.


In this manner, solution development proceeds—one story, feature, capability, and nonfunctional requirement at a time, until the ultimate goal of the release. However, before all that new functionality can be actually released to Customers, some final activities, including solution verification and validation, documentation, and supporting activities are typically necessary.

The release process may also involve the transition of the solution assets to another business unit, or even to a different organization that is responsible for actual delivery to the Customer. For example, the system, in the form of designs, can be released to manufacturing engineering, where the actual fabrication instructions are finalized. In other cases, the solution can be released as is, but the delivery process requires considerable effort and is a major project of its own (in order to be useful, a satellite needs to be sent into its orbit). In either case, there are usually significant risks associated with the release process that may prevent the whole program from succeeding (examples: a new motion base is too costly to manufacture, or the satellite launch imposes too much vibration on the satellite).

The best way to prevent release issues is by:
a) Designing the solution and the process with “release-ability” in mind
b) Validating those assumptions as early and frequently as possible

In order to solve (a), the Economic Framework, the Value Stream Kanban, and the rest of the decision-making tools have to reflect the key release concerns. The system itself also needs to satisfy the nonfunctional requirements, which reflect, in part, release constraints. The PI Planning and Pre-and-Post PI Planning meetings are great occasions to involve people who can speak to the release aspects of the solution, and to assist the trains and teams in better understanding what building releasable increments entails.

To satisfy (b), a frequent validation/feedback model is required. In some cases, more frequent external releases are extremely helpful. In other instances, when releasing frequently is not possible, is too expensive, or is otherwise constrained, this type of validation needs to happen at the solution increment level at least every PI, though it may require special procedures and infrastructure to verify release-ability by emulating some or all of its aspects. The IP iteration can provide a helpful timebox for this.

A Scaled Definition of Done

Taken together, the continuous buildup of system functionality, along with continuous verification and validation of the elements of the solution, as well as the final solution itself, can be reflected in a scaled Definition of Done. See the example illustrated in Table 1.

Table 1. Example SAFe scalable Definition of Done
Table 1. Example SAFe scalable Definition of Done


Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

Last update: 21 April 2016