The end of a thing is never the end; something is always being born…

– Lucille Clifton

Develop on Cadence. Deliver on Demand.
– Dean Leffingwell

PSI/Release Abstract

In SAFe, every agile team builds assets incrementally, resulting in new working software, at worst every two weeks (every day is the goal). However, for a number of technical and business reasons, many enterprises do not wish to release that frequently. Others need to release solutions, or components of solutions, at that frequency or even faster. In support of this needed flexibility, SAFe provides a cadence-based approach to creation of valuable and evaluate-able Potentially Shippable Increments (PSI/Release), each of which reflects a milestone, including assured integration and testing of all software assets across all teams in a Program. On the Big Picture, we call this milestone a PSI/Release.

In some situations, each PSI/Releases released to the external users, in which case the PSI is also a release. Others enterprises will need to release less or more frequently than the PSI/Release cadence. In all cases, the PSI is a development timebox (uber-sprint) that uses cadence and synchronization to facilitate planning, provide for aggregation of newsworthy value, and provide a quantum unit of thinking for portfolio level consideration and roadmapping. And while continuous integration and system validation is always the goal, the PSI/Release timebox can also provide a forcing function to reduce the risk of deferred integration, and even worse, deferred or slow internal or external customer feedback.

Details

What is a PSI/Release?

As we described, programs can release assets to market at any time they meet quality/governance and market/business needs criteria. So the PSI/Release cadence is typically NOT the release cadence. Rather, a PSI/Release provides a strategic quantum of timebox and value to the Program and enterprise with the following features:

A routine and continuous planning cycle. This provides a planning cadence which lowers the transaction cost of planning and makes planning routine. It periodically aligns teams to a common mission, while limiting deviation from plan and concomitant business expectations to a single, short time interval
An aggregation of iterations value into larger piles of newsworthy value. Every sprint, every team produces working, tested new increments of software. Over time, these add up to larger and larger, newsworthy value, thereby providing a mechanism to manage the flow of new value via announce-able releases to customers, stakeholders and analysts
A quantum unit of thinking, roadmapping, implementing and measuring. In the enterprise, teams and iterations are small and fast, too small and fast to allow for appropriate attention. The PSI aggregates work into value and timeboxes that the enterprise can focus attention on, in support of planning and roadmapping, execution, getting feedback, measuring and adapting.

The PSI/Release as an Uber-sprint

Perhaps a simpler way to view a PSI/Release is as an “uber-sprint”. The sprint cycle is well known and repetitive: plan-commit-execute-demo-retrospect. This is a simple, trusted and effective model, as illustrated in Figure 1.

Figure 1. The Standard Sprint Pattern

The lean benefits of such a cycle include: timeboxing to limit work in process and keep the queues short (sprint backlog is a small subset of the team backlog); fixing scope for short periods aligns the team members to the work, provides focus and fosters small successes for people; synchronization helps assure system integration, robustness, demonstrability, and fast feedback for each increment, and finally, kaizen mind is assured through cadence-based reflection and continuous improvement.

At the Program Level, the challenge is even larger and the benefits of a similar approach are larger still. Therefore, we move one “fractal” above the sprint and scale:

Backlog—by introducing Vision, Features and Nonfunctional Requirements as higher-level value artifacts, and by using lean economics to prioritize value sequencing with WSJF.
Teams—by introducing Release Train Engineer (uber scrummaster), Product Management, System Team, Release Management, and UX and Architectural guidance
Timebox— scale up to an 8-10 week timeframe whereby the enterprise can focus on the results. Drive continuous improvement be Inspecting and Adapting at each Program Level PSI/Release boundary.

The net result is an uber-sprint, as illustrated in Figure 2.

Figure 2. The PSI “Ubersprint” pattern

Separating Development Concerns from Release Concerns

Continuous end-to-end sequencing of PSI/Release creates The Agile Release Train, which simplifies development. However, we still need to address another challenge, which is an understanding of when to actually release a set of assets. SAFe provides a model that allows for separation of concerns to achieve a higher degree of flexibility and greater market impact. Figure 3 illustrates this model:

Figure 3 Develop on Cadence. Deliver on Demand

This model decouples asset development from product release via a “general availability firewall”. The development team is free to establish the best development rhythm, continuously building incremental product functionality. Marketing/Distribution is free to deploy external releases as necessary.

With this conceptual model, we consider three separate cases for releasing.

Releasing on the ART Cadence

The simplest conceptual case is to release on the PSI/Release boundaries, as planning, releasing, and release retrospectives are coordinated by the same cadence and calendar dates. In addition, HIP (Hardening | Innovation | Planning) iterations can be timed and coordinated to support the more extensive release activities, which can including release notes and customer documentation, user acceptance testing, standards validation, load and performance testing, and the like. This is the model used by a number of SaaS (Software as a Service) companies.

Releasing Less Frequently

In many cases, however, releasing on a fast PSI/Release cadence may not be possible. For example, in some enterprise settings, deployed systems constitute critical infrastructure of a customer’s operating environment. Even if the customers would like to have the new software, service level and license agreements may be prohibitive and there is the overhead and disruption of installation. In other cases, the timelines of enterprises building systems that contain both software and hardware, such as mobile phones, are driven by long-lead hardware items – displays, chip sets, and the like. The new hardware must be available first, so releasing early and incrementally is not an option. In these cases, releasing on a PSI cadence is simply not an option and the planning and releasing activities must be decoupled.

Releasing More Frequently

For enterprises who are building systems of systems, either of the two cases above may still be overly simplistic. In these cases, while the larger system may lend itself to either of these models above, various components of the system may have to be released more frequently. In this case, the PSI/Release cadence becomes a planning, rather than release cadence. The periodic planning function still provides the cadence, synchronization and alignment the enterprise needs to manage variability and limit deviations from expectations, but forcing the development of all assets to the same cadence is unnecessary, and over-constrains the system.

In all cases, enterprises who apply SAFe can rest easy with the fact that development and releasing are not the same thing, and they can release any quality asset at any time required to meet business conditions.

Learn More

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

Last updated 24 March, 2013