How SAFe approaches releasing

While a Program Increment spans 3 months, While at the end of these 3 months, there is a "Solution Demo" where all Release Trains demonstrate a Working Product, SAFe suggests "Release Any Time". This is not to be confused with "Release at the end of every increment". Let's clear up what the intention is.

Developer perspective

One of the biggest plagues of Waterfall software development is the "Integration phase", where developers bring together the different pieces of work and try to patchwork it into a shippable product. Martin Fowler described "Integration hell" and the corresponding solution, Continuous Integration, a long time ago. SAFe suggests applying Continuous Integration, combined with scrutinous test automation, on a developer level.

Every developer should aspire to keep the product shippable at any time. After every commit, the product should be "done" in regards to the work invested up to this point. There is no place for "loose ends".

Team perspective

Every team works on their specific stories and objectives. Whenever developers feel that they are ready to deliver a specific piece of work, maybe even just a fragment of a user story, it's up to the team what to do with the result. SAFe encourages delegating Micro-Decisions, such as whether to release the new "Search" function for our Website, directly to the teams doing the work. 

In the same breath, teams should have both the authority and technical capability of delivering their value when they feel is the right time. Continous Deployment is a wonderful way of accomplishing this wherever possible.

Release Train perspective

The Release Train, a "team of teams", builds Features - major blocks of customer value. In some cases, these features do require a lot of upfront work and big-batch releasing. For example, "The new iPhone" requires "a new iOS", "a new battery" and "a new chassis": You can't just deliver the new battery whenever you want. It's just a new feature that has no market value until it can be integrated into a shippable product. And this "integration" is not just software level. It includes setting up a physical production chain - and potentially tons of legal paperwork that could take months to complete: That's just not what you do 27 times a day.

The decision to insert a completed major feature into the current product is beyond a single team's sphere of control. The Release Train must be ready and overall willing to deliver the product with this new feature. This does not mean that the date is either preplanned in complete disregard of development reality - or that the feature sits as inventory until a PI end date is reached.

This is where PI planning is a major boon: When teams need to collaborate on big batches, it does make sense to put the product milestones onto a common plan, so that everyone knows what needs to be done by when.

Value Stream perspective

In some cases, the product development is so massive that multiple Release Trains need to collaborate. Resorting to the example that Mike Cohn also uses, of developing an Office Suite, the Train in charge of the Word Processor can't simply decide to release "The New Office". They can deliver features into Word, they can deliver bugfixes - but they can't control the entire campaign surrounding Your Office.

Decisions to bring new Capabilities to the market are made on the level where the different trains in the same value stream come together. While product releases are made completely independent of cadence, the Solution Demo is a good way to give and receive feedback regarding whether it makes sense to proceed with releasing.

Portfolio perspective

In exceptional situations, even a completed product needs to be kept off the market for maximum effect. There may be strategic appointments defining when a product needs to hit the market - no sooner, and no later. In these cases, even the Value Stream has no influence on releasing. An example could be a government contract to deliver a new Public Security Monitoring application. While demos, piloting or potentially even localized initial trial runs of individual features and capabilities are well within the ability of the teams, trains or value streams - releasing a major milestone into the market comes with a lot of media buzz and the potential for devastating repercussions. 

In such extreme scenarios, Epic batches may need to withheld from official release despite internal agreement that go-to-market is possible.

Summary

Releasing in SAFe follows the 9th Lean-Agile principle, "delegating decisions to the lowest possible level" - encouraging the release of value at the earliest possible date where it makes sense, reaping value as soon as possible and maximizing opportunities for feedback learning. SAFe does not  encourage big batching, yet it provides a clear approach to dealing with situations where batching is inevitable.