Control flow under uncertainty.

—Don Reinertsen


Develop on Cadence

Develop on Cadence is a strategy for managing the inherent variability in solution development by making sure important events and activities occur on a regular, predictable schedule.

A fundamental strategy for managing the inherent variability in systems development in a flow-based system is to execute routine development activities on a fast, synchronous cadence—a regular, predictive rhythm of important events.

Cadence makes routine that which can be routine, assures that important events happen—like system integration for example— and it lowers the cost of standard events. This is a fundamental premise of SAFe, and its effects can be seen directly on the Big Picture—with the fast cadence of synchronized, short Iterations, which are then integrated into larger Program Increments (PIs).

Note: This article is the companion article to Release on Demand.


Cadence and synchronization are the key constructs we use to build our Solution assets. So when we say develop on cadence, we really mean both. Cadence is the use of a regular, predictive development rhythm. Synchronization causes multiple, and potentially dependent, events to happen at the same time.

Together, cadence and synchronization allow us to make routine that which can be routine, including PI Planning, System and Solution Demos, and system integration, as well as less frequent items such as adjusting resources and realigning work to teams. These principles (thanks to Don Reinertsen, Principles of Product Development Flow [1]) are so critical to understanding why SAFe works the way it does that we describe some of Reinertsen’s basic principles—along with how SAFe applies them—in Tables 1 and 2 below.

Principles of Flow: Cadence SAFe Practices
F5: Use a regular cadence to limit the accumulation of variance Planning at regular Program Increment (PI) intervals limits variances to a single PI timebox, thereby increasing Agile Release Train and Solution Train predictability.
F6: Provide sufficient capacity margin to enable cadence In order to reliably meet PI objectives, the Innovation and Planning iteration  has no planned scope, and thereby provides a schedule margin. In addition, uncommitted, but planned for, stretch goals provide capacity margin. Together they provide the schedule and scope margin needed to reliably meet PI goals.
F7: Use cadence to make waiting times predictable If a Feature doesn’t make it into a PI  and it remains high priority, its delivery can be anticipated to be on schedule in the next PI (or an other scheduled, frequent release), thereby avoiding the temptation to load excess WIP into the current increment.
F8: Use a regular cadence to enable small batch sizes Short iterations help control the number of Stories in the iteration batch. Feature batch sizes are controlled by short PIs and frequent releases, providing high system predictability and throughput.
F9: Schedule frequent meetings using a predictable cadence PI planning, iteration planning, PO Sync, backlog refinement, Inspect and Adapt, architecture discussions, etc., all benefit from frequent meetings. Each meeting needs to process only a small batch of new information. Cadence helps lower the transaction costs of these meetings.

Table 1: Cadence principles applied in SAFe


Principles of Flow: Synchronization SAFe Practices
F10: Exploit economies of scale by synchronizing work from multiple projects Individual Agile Teams are aligned to common iteration lengths. Work is synchronized by system and solution demos. Portfolio business and Enabler Epics drive common infrastructure and Customer utility.
F11: Capacity margin enables synchronization of deliverables Teams plan with stretch objectives; these are sacrificed as necessary when plans meet reality.
F12: Use synchronized events to facilitate cross-functional trade-offs Value stream and program PI events synchronize Customer feedback, resource and Budget adjustments, mission alignment, inspect and adapt improvements, and program review and governance. They also drive collaboration and team-building.
F13: To reduce queues, synchronize the batch size and timing of adjacent processes Teams are aligned to common timeboxes and similar batch sizes. The ART and Solution System Teams supports integration on a regular cadence. Backlogs are kept short and uncommitted to support rapid delivery of new ideas.
F14: Apply nested cadence harmonic multiples to synchronize work Teams integrate and evaluate (at least) on iteration boundaries; programs and value streams integrate and evaluate on PI boundaries.

Table 2: Synchronization principles applied in SAFe

Taken together, cadence and synchronization are critical concepts that help us manage the inherent variability in our work. This creates a more reliable, dependable software development and delivery process, one that our key business stakeholders can come to rely on.

But Release on Demand

As we have seen, developing on cadence delivers many benefits, but when it comes to actually releasing value, a different set of rules may apply. Given a reliable stream of Program Increments, the next and even larger consideration is to understand when and how to actually release all that accumulating value to the end user. As we describe in the Continuous Delivery Pipeline and Release on Demand, every Agile Release Train (ART) and Solution Train has to have a strategy for releasing software that suits its development and business context.

Toward Continuous Delivery

For many, the prospect of continuous delivery may represent a desired end state. After all, none of us panic when an automatic update becomes available for our phone; we assume it will deliver value and hit that update now button without much thought or concern. And surely there is as much or more software in that phone than there is in some of our enterprise systems. However, the enterprise world often marches to a different drummer. Perhaps, for reasons of security and availability, or for financial (banking, trading) or personal (medical equipment, man-rated systems) criticality, the customer’s operational environment may not be suited to continuous updates of significant new value. Perhaps our enterprise’s development and release capabilities have not advanced to the point where that is a largely risk-free approach for our Customers. Perhaps, for whatever reason, it just doesn’t make economic sense.

In addition, systems that support continuous delivery must be designed for continuous delivery. Even then, releasing is not a homogeneous thing. Even this simple website has multiple release paradigms. If, for example, we updated the Big Picture every week, those supporting SAFe with tooling and courseware would not think that was a good approach. At the same time, if we didn’t have the ability to roll out new content (through the blog, Guidance, and updates to articles), we’d be inhibited in our goal of continuous value delivery. We couldn’t be as Agile. You have to design for these things.

In all cases, enterprises that apply SAFe can rest easy in the knowledge 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

[1] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007, chapter 16.

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

Last update: 22 May 2017