nav-program-release

Deliver software frequently; from a couple of weeks to a couple of months, with a presence for the shorter time scale.

Agile Manifesto

Things done well and with care, exempt themselves from fear.

William Shakespeare

Release Abstract

The Framework focuses on the development of large scale, complex system and software solutions. But our goal isn’t to just to develop working software. Rather it is to continuously define, develop, validate, deploy and support it in our customer’s environment. Only there can they receive the benefits of our latest innovations—new features, increased quality and enhanced performance. A constant stream of delivered value, that’s the goal of every ART and value stream.  In this article, we’ll describe how we build the Release, which consists of working software, and other necessary elements of a releasable solution.

Details

Frequency of Release

The goal is clear: to deliver software frequently. However, how frequently is based on our customers context, not just our own, and therefore we require significant flexibility in the approach.SAFe’s Develop on Cadence. Deliver on Demand mantra guides this thinking, and provides a separation of concerns so that we can apply a disciplined development cadence to manage the inherent variability in our R&D world, while delivering whenever we need to. This can be synchronously, asynchronously—or more likely some combination—as Figure 1 illustrates.

 

Figure 1. Develop on Cadence. Release on Demand

Figure 1. Develop on Cadence. Release on Demand

 

Quality Features Build User Value

In SAFe, Features are the primary carrier of value to the user. Features are prioritized using WSJF and are pulled from the Program Backlog based on emerging program capacity. Features have acceptance criteria, which we use to accept new features into the baseline in accordance with a Definition of Done (below). Simply, building and accepting features is the primary way of building measurable value.

But teams don’t code features directly, rather features are implemented by User Stories, which, in turn, are validated by unit tests and story acceptance criteria. This provides inherent, and built in quality via verification that the stories and the code deliver the desired feature functionality.

Note: Verification and Validation of high assurance software is a deeper topic than we can cover here. For those building such systems, or for anyone building systems where defects may have an unacceptably high impact, see the Guidance articles Agile Development in High Assurance and Regulated Environments, and the Agile Software Requirements Model.

Working Software: A Potentially Releasable Increment

Prior to Agile, a release was usually predefined by some set of requirements documents, which defined the functionality necessary for a release. The release itself was a big-bang effort that happened at the end. (Note: for many doing Agile development in fixed-price/fixed-requirements/fixed-delivery settings, that may still be the initial expectation.)

In Agile, however, our immutable goal is to always have continuously demonstrable and potentially releasable software, so the release question becomes “when do we have sufficient new functionality (the right batch size, for us and our customer) to warrant release?” This question is answered not once, but continuously. That’s what creates the continuous flow of value.

Generally, SAFe programs think in terms of potentially releasable increments, a “box “of tested working software which provides an always-growing set of new functionality, one that exhibits the following characteristics.

  • Conceptual integrity. The features in the release provide a set of capabilities that are logically independent, or if dependent, cooperate in such a way as to achieve some higher user goal.
  • Feature Toggles. Some future functionality, which is not yet suitable for end user exposure, is always under development. Teams use feature toggles to selectively disable, and re-enable the cool, newer, maybe-not-ready-for-prime-time stuff.
  • Architectural Robustness. Extension, redesign and refactoring of the underlying architectural runway is always under way as well. Some of this work may need to be switchable, or scaffolded, in such way as so as to not interfere with the logical and reliable behavior of the system.

In this way, each potentially releasable increment contains of set of functionally consistent features—new and existingas illustrated in Figure 2.

Figure 2. Potentially Releasable Feature Set

Figure 2. A potentially releasable, functionally consistent, feature set.

From Potentially Releasable to Releasable

The continuous availability of a potentially releasable feature set is the goal of the agile program. However, before all that new functionality can be actually delivered to our customers, two additional steps may be required. These are described in the paragraphs below.

System Validation

Before deployment, our potentially releasable increment of tested working software will likely require some final validation testing; testing that was simply technically or economically not feasible during the course of every sprint or PI. This can include activities like final load and performance testing, testing in the deployment environment, user acceptance testing, validation of satisfaction of adherence to regulatory and other standards based requirements, integration with larger parts of the system or 3rd party components. Generally these are the types of tests that occur in Quadrant 3 and 4 of the Agile Testing Matrix, as  shown in Figure 3 below.  (Note: see Test-First for a discussion of this matrix),

Figure 3. System Validation with the Agile Testing Matrix

Figure 3. System validation testing with the Agile Testing matrix

 

Quadrant 4 highlights systems qualities test (Nonfunctional requirements), tests which help assure that the system meets the requisites system qualities. Many of these tests will have been integrated into the flow of development and thereby most of this assurance should have been continuously achieved.  However, it is often the case that certain of these tests can be run only with specialty tools, configurations, environments or licenses, so some final validation testing may still be required.

Quadrant 3 is the realm of System Acceptance Testing, tests that assure the full, as built and configured, system performs to the users requirements.  Again, much of this testing has already been integrated into the development practices as well via continuous customer feedback, but there are typically some final quality checks required.  These can include scenario tests, exploratory tests and user acceptance tests, whatever is necessary to assure that we have actually built what the customer really wanted, and it is fit for use.

Once these activities are complete, our working software takes the form of a validated system, as illustrated in Figure 4.

Figure 4. Validated System

Figure 4. A Validated system with new features

 

Capturing Verification and Validation in a Scalable Definition of Done

Perhaps the easiest way to summarize the above discussion is to incorporate all this thinking into a Scalable Definition of Done, an example of which appears in Table 1 below.

Table 1. Scaled Definition of Done

Table 1. Scaled Definition of Done

In this DoD, it is clear that verification and validation are continuous processes, supported by our technical quality practices, and continuous system level integration and validation. The only things left until prior to release, are things that which are not technically or economically feasible earlier (examples: field testing of a crop combine in an actual field for example, or user testing in the user’s actual production environment).

Completing the Solution

And finally, there are some additional activities, primarily documentation, that are usually necessary prior to shipment to the end user. These may include

  • Release notes and other user notices
  • Internal and external communications
  • Finalization of end user documentation
  • Release packaging, bill of materials, configuration guides
  • Installation/deployment documentation
  • Training and documentation for support personnel
  • Quality management systems documentation (high assurance)
  • Approvals and signoffs

When these activities are completed, we are truly shippable, and as Figure 5 indicates, our whole solution can now be deployed to deliver its intended benefits.

Figure 5. A Releasable Solution

Figure 5. A releasable solution

 

Summary

The mission of every Agile team and Agile Release Train is the continuous development of tested, working, and always-potentially-releasable, software.  Accomplishing this requires high quality coding practices, as well as continuous verification and validation of fitness for use. In addition, there is typically some final, pre-shipment validation and documentation activities that are necessary for successful deployment to end users. Producing software in small increments (small batch sizes) on a fixed cadence helps Agile teams achieve this goal. Decoupling the development cadence from the release process provides an effective separation of these concerns, and helps Agile Release Trains accomplish their mission of releasing software frequently, as the market demands.

 


Learn More

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

Last update: 7 May, 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.