Control flow under uncertainty.

—Don Reinertsen

 

Develop on Cadence

Develop on Cadence is an essential method for managing the inherent variability of systems development in a flow-based system, by making sure important events and activities occur on a regular, predictable schedule.

The effects of cadence can be seen directly on the Big Picture—with fast synchronized short Iterations, which are then integrated into larger Program Increments (PIs). Cadence assures important events such as—PI Planning, System and Solution Demos, and Inspect & Adapt happen on a regular, predictable schedule. It also lowers the cost of these standard events by enabling them to be planned well in advance.


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


Details

Cadence, along with synchronization, is a key construct used to build system and Solution assets in SAFe. Cadence is the use of a regular, predictive development rhythm, while synchronization causes multiple, potentially dependent events to happen at the same time.

Thanks to Don Reinertsen’s principles of product development flow [1] we can explain why cadence and synchronization are critical to effective solution development. Some of these principles are summarized in Tables 1 and 2 below, along with the relevant SAFe practices that implement them.

Principles of Flow: Cadence SAFe Practices
F5: Use a regular cadence to limit the accumulation of variance Planning at regular PI intervals limits variances to a single PI timebox, increasing Agile Release Train (ART) and Solution Train predictability.
F6: Provide sufficient capacity margin to enable cadence In order to reliably meet PI objectives, the Innovation and Planning (IP) iteration has no planned scope and provides a schedule margin (buffer). In addition, uncommitted but planned-for stretch goals also provide capacity margin (scope buffer). Together, they offer a way to reliably meet PI goals.
F7: Use cadence to make waiting times predictable If a Feature doesn’t make it into a PI but remains a high priority, its delivery can be scheduled for the next PI (or another scheduled, frequent release). This avoids the temptation to load excess Work in Process (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, System Demos, Inspect and Adapt (I&A), ART Sync, Iteration Planning, backlog refinement, and architecture discussions are examples of things that 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 The Innovation and Planning (IP) iteration enables the final PI system demo, and solution demo to occur without taking velocity away from ARTs or Solution Trains.
F12: Use synchronized events to facilitate cross-functional trade-offs ART and Solution Train events synchronize customer feedback and enable resource and budget adjustments, mission alignment, continuous improvement, and program oversight 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 support integration on a regular cadence. To facilitate the rapid delivery of new ideas, backlogs are kept short and uncommitted.
F14: Apply nested cadence harmonic multiples to synchronize work Teams integrate and evaluate on iteration boundaries (at least). ARTs and Solution Trains 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 of our work. This creates a more reliable, dependable solution 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 cadence of PIs, the next and even larger consideration is to understand when and how to actually release all that accumulating value to the end user. As described in the Continuous Delivery Pipeline and Release on Demand articles, every ART and Solution train needs a strategy for releasing solutions that suits its development and business context. The release strategy is decoupled from the development cadence, as shown in Figure 1.

Figure 1.  Decoupling development concerns from release concerns

Several release strategies may apply depending on the context and situation:

  • Releasing on the Program Increment (PI) cadence – The simplest case is when an enterprise can release on the PI boundaries. It’s simplest because PI planning, releasing, and Inspect and Adapt will have predictable calendar dates. Also, the Innovation and Planning Iterations can be timed, designed, and organized to support the more extensive release activities. The IP iterations may include final, Verification and Validation (V&V), User Accepted Testing (UAT), and training and release documentation.
  • Releasing less frequently – In many cases, however, releasing on a fast PI cadence may not be possible or even desirable. For example, in some enterprise settings, deployed systems constitute critical infrastructure for an operating environment. Even if the customer would like to have the new software, the service level, and license agreements may be prohibitive. And then there is the overhead and disruption of deployment. In other cases, the timeline for building complex systems with both software and hardware (e.g., mobile phones or geophysical mapping satellites) are driven by their hardware components (displays, chipsets, and the like), which typically have longer lead times. The new hardware must be available first, which means releasing early and incrementally may not be an option. In these cases, releasing on a PI cadence may not be practical, and the planning and releasing activities are entirely decoupled.
  • Releasing more frequently – For many, the goal is to release as often as possible—hourly, daily, weekly, and so on. Achieving frequent releases requires DevOps capabilities, an efficient continuous delivery pipeline, and architecture that supports incremental delivery. Even then, the periodic planning function still provides the cadence, synchronization, and alignment the enterprise needs to manage variability and limit deviations from expectations.
  • Release on demand – For organizations building complex solutions (e.g., systems of systems), the cases above are probably overly simplistic. Big systems often contain different types of components and subsystems, each of which may leverage its release model. In that case, the most general model is: Release whatever you want and whenever it makes sense, within an appropriate governance and business model.

Developing on cadence while releasing whenever there is business demand is, therefore, an important combination.


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: 2 October 2018