Develop on Cadence

Image

Control flow under uncertainty.

Don Reinertsen

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 in the Big Picture—with fast synchronized short Iterations being completed and then integrated into larger Program Increments (PIs). Cadence assures that important events such as PI Planning, System and Solution Demos, and Inspect & Adapt (I&A) workshops happen on a regular, predictable schedule. It also lowers the cost of these standard events by enabling them to be planned well in advance.

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, along with the relevant SAFe practices that implement them.

Principles of Flow: Cadence

SAFe Principles

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 (l&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 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. They create 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 chapters, every ART and Solution train needs a strategy for releasing solutions that suits its development and business context.

Toward Continuous Delivery

For many organizations, the prospect of continuous delivery is highly desirable. After all, none of us panics when an automatic update becomes available for our mobile phone. Rather, we assume it will deliver value, and we press that update button without much thought or concern. Surely there is as much or more software in that phone as in some of our enterprise systems.

Nevertheless, the enterprise world often marches to a different drummer. Perhaps, for reasons related to security and availability, or for financial or safety-critical systems, the customer’s operational environment is ill suited to continuous updates of significant new value. Perhaps our enterprise’s development and release capabilities have not advanced to a point where such updates are a largely a risk-free proposition for our customers. Perhaps, for whatever reason, continuous updating just doesn’t make economic sense.

In addition, systems that support continuous delivery must be designed for that outcome. Even then, releasing is not an all-or-nothing event. For example, even the simple SAFe website has multiple release cadences. If, however, we updated the Big Picture every week, the people supporting SAFe with tooling and courseware would think that was a bad approach. However, without the ability to roll out new content (through the blog, supplemental guidance articles, and updates to existing articles), we’d undermine our goal of continuous value delivery. We couldn’t be as Agile. In short, you have to design for these things.

In all cases, enterprises that apply SAFe can rest easy knowing that development and releasing are separate concerns. They can release any quality asset, as needed, 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.