Control flow under uncertainty.
Deliver software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale .
Develop on Cadence. Release on Demand. Abstract
Develop on Cadence. In a flow-based system, basing routine development activities on a fast, synchronous cadence—a regular predictive rhythm of important events—is our best strategy for managing the inherent variability in systems development. (Building, complex, large scale software systems is, after all, research and development). This is one of the fundamental premises of SAFe, and its effects can be seen directly on the Big Picture with the fast cadence of synchronized short iterations, and the further integrations of those iterations into larger Program Increments.
Release on Demand. However, SAFe provides a separation of concerns which provides the development teams with the cadence and synchronization tools they need to manage the complexity and rapid change in their environment, while allowing for either synchronous or asynchronous releases to the market. This is another of the fundamental premises behind SAFe, and it is also expressed directly in the Big Picture by those little iconic, boxes of working software.
Details: Develop on Cadence
Cadence and Synchronization are the key constructs we used to build our software assets. Cadence is the use of a regular, predictive development rhythm. Synchronization causes, multiple, dependent events to happen at the same time. Together, cadence and synchronization allows us to make routine that which can be routine, including planning, demos, system integration, as well as less frequent items such as adjusting resources and realigning work to teams. These principles are so critical to understanding why SAFe works the way it does, that we describe some of these basic principles – along with how SAFe applies them – in Tables 1 and 2 below.
|Principles of Flow: Cadence||SAFe Practices|
|PPDF F5: Use a regular cadence to limit the accumulation of variance||Planning at regular Program Increment intervals limits variances to a single PI timebox, thereby increasing ART program predictability|
|PPDF F6: Provide sufficient capacity margin to enable cadence||In order to reliably meet PI objectives, the Innovation and planning sprint is unplanned and provides schedule margin. Uncommitted, but planned, stretch goals provide capacity margin. Together they provide the schedule and scope margin needed to reliably meet PI goals.|
|PPDF F7: Use cadence to make waiting times predictable||If a feature doesn’t make it into a PI (or Release), and it remains high priority, it can be anticipated to be delivered on schedule in the next PI (or scheduled, frequent Release), thereby avoiding the temptation to load excess WIP into the current increment.|
|PPDF F8 : Use a regular cadence to enable small batch sizes||Short sprints 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|
|PPDF F9: Schedule frequent meetings using a predictable cadence||Release planning, sprint planning, backlog refinement, Inspect and Adapt, architectural discussions, etc., all benefit from frequent meetings, each needing to process only a small batch of new information. Cadence helps lower transactions costs of meetings and other significant events.|
Table 1: Cadence Principles Applied in SAFe
|Principles of Flow: Synchronization||SAFe Practices|
|PPDF F11: Exploit economies of scale by synchronizing work from multiple projects||Individual agile teams are aligned to common sprint lengths. Work is synchronized by System Demos. Portfolio epics drive common infrastructure and customer utility|
|PPDF F10: Capacity margin enables synchronization of deliverables||Teams plan with stretch objectives; sacrificed as necessary when plans meet reality|
|PPDF F12: Use synchronized events to facilitate cross functional tradeoffs||Program Increment events synchronize customer feedback, resource and budget adjustments, mission alignment, inspect and adapt improvements, program review and governance, and drive collaboration and team building|
|PPDF F13: To reduce queues, synchronize the batch size and timing of adjacent processes||Teams are aligned to common timeboxes and similar batch sizes. System team supports integration on cadence. Backlogs are kept short and uncommitted to facilitate rapid delivery of new ideas|
|PPDF F14: Apply nested cadence harmonic multiples to synchronize work||Teams integrate and evaluate (at least) on sprint boundaries; programs integrate and evaluate on PI boundaries|
Table 2: Synchronization Principles Applied in SAFe
Taken together, Cadence and Synchronization are important 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.
Details: Release on Demand
As we have seen, developing on cadence is indeed well and good, but when it comes to actually Releasing value, a different set of rules may apply. Given a reliable stream of potentially shippable increments, the next, even larger consideration is to understand, when and how to actually release all that accumulating value to the end user. The Big Picture illustrates releases at various times during the flow of each Release Train. But that’s just a picture, and every enterprise, and every program, has to have strategy for releasing software that suits its development and business context. In the next section, we’ll discuss considerations with respect to release frequency.
Towards 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 our enterprise systems. However, the enterprise world often marches to a different drummer. Perhaps, for reasons of security and availability, or financial (banking, trading) or personal criticality (medical equipment, man-rated systems), the customer’s operational environment may not be suited to continuous updates of significant new value. Perhaps, our enterprises development and release capabilities have not advanced to the point where that is a largely a 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 homogenous thing. Even this simple web site 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 thing. At the same time, if we didn’t have the ability to roll out new content (through the blog, Guidance and rolling wave updates to Coming Soon articles), we’d be inhibited on our goal of continuous value delivery. We couldn’t be as Agile. You have to plan for these things.
Separating Development Concerns from Release Concerns
We must then recognize that developing and releasing software may be unlike things. For maximum flexibility and agility, SAFe provides a separation of concerns to decouple these potentially unlike events. Each program defines the development cadence of their specific Agile Release Train when it picks their iteration pattern. (We also note that while the Big Picture illustrates five sprints per Program Increment, that is arbitrary and individual programs can pick whatever cadence best suits their abilities and context.) With this conceptual model, we can consider three separate cases for releasing.
Releasing on the Program Increment Cadence. The simplest case is when an enterprise can release on the Program Increment boundaries. It’s simplest because Release Planning, releasing, and Inspect and Adapt retrospectives are coordinated by the same cadence and calendar dates. In addition, Innovation and Planning iterations can be timed, designed and coordinated to support the more extensive release activities, which can including system validation, UAT, release documentation, etc. Plus, all release dates can be known well in advance! (Fix the date; float the scope.) If a company wants the efficiency and convenience of this model, and since the overall PI pattern is arbitrary, many enterprises find there way to this simple construct.
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 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 as a mobile phone or geophysical mapping satellite, 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 PI cadence may not be an option and the planning and releasing activities may be completely decoupled.
Releasing More Frequently. For enterprises building complex systems of systems, either of these above two cases are probably 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. 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 release of all assets to the same cadence is unnecessary, and over-constrains the system.
Let’s be practical. Big systems are not homogenous. They may contain different types of components and subsystems, each of which require their own release model. So elements of each of these three models above may all be present at the same time, in which case it’s probably easiest to consider the most general model: release whatever you want whenever it makes sense, as the example in Figure 1 illustrates.
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.
 Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
 Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007, chap.16.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 22 July, 2014
This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.