Doing is a quantum leap from imagining.
—Barbara Sher
A Program Increment (PI) is a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems. PIs are typically 8–12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration.
A Program Increment is to an ART (or Solution Train) as an Iteration is to the Agile Team. In other words, the PI is a fixed timebox for building and validating a full system increment, demonstrating value, and getting fast feedback. Each PI uses cadence and synchronization to accomplish the following goals:
Facilitate planning
Limit Work in Process (WIP)
Summarize newsworthy value for feedback
Assure consistent, Program Level retrospectives
Due to its scope, the PI provides several observations appropriate for Portfolio Level consideration and ‘roadmapping.’
SAFe divides the development timeline into a set of Iterations within a PI. The Big Picture illustrates how a PI is initiated by a PI Planning session, which is then followed by four execution iterations, concluding with one Innovation and Planning iteration. This pattern is suggestive but arbitrary, and there is no fixed rule for how many iterations are included in a PI. Experience has shown, however, that a PI duration between 8 and 12 weeks works best, with a bias toward the shortest duration.
A Solution Train and its associated Agile Release Trains use the same PI cadence, as shown in Figure 1.
The PI represents the outer loop of Shewhart’s PDCA cycle, as shown at the top of Figure 1. It combines the value developed by each Agile Team into a meaningful Milestone to objectively measure the Solution under development.
The PDCA learning cycle (shown in Figure 1) is represented by the following events in SAFe for the PI (outer loop):
Plan – The PI Planning event is the plan step of the cycle.
Do – PI execution is the do step.
Check – The System Demo is the check step.
Adjust – The Inspect and Adapt (I&A) event is the adjust step.
Continuous execution of PIs provides the rhythm for trains, and the assets they create grow iteratively and incrementally. Releasing solutions, however, is a separate concern, which is covered in the Release on Demand chapter. While trains determine the best product development rhythm, the business is enabled to deploy releases whenever it, or the market, requires.
The cadence for the PI can be different from the release cadence. However, in some situations, the PI and release cadences are the same, which can be a major convenience. Other ARTs may need to release less or more frequently than the PI cadence. Still others will have multiple, independent release cycles for the solution’s various components.
When it comes to PI execution for a single ART, a sequence of program events creates a closed-loop system to keep the train on the tracks, as illustrated in Figure 2. Each program event is described in the following sections.
Each PI begins with a PI planning event. Since PI planning occurs on a fixed cadence, the entire calendar year of events can be scheduled well in advance. By scheduling PI planning events in advance, the enterprise can lower the cost of travel and logistics. In addition, this advance scheduling helps people on the train, especially Business Owners, to manage their personal calendars to assure they can be present for these critical events.
During PI planning, the teams estimate what will be delivered and highlight their dependencies with other Agile teams and trains. PI planning also creates a rhythm for integration of work and system demos. One outcome of the PI planning is a set of program PI Objectives, detailing what the ART should have ready for integration and demo at the end of the PI. Of course, Agile teams continuously integrate their work and demo it during the Iteration Review and System Demo (or Solution Demo for Solution Trains).
The Release Train Engineer (RTE) typically facilitates a weekly (or more frequent, as needed) Scrum of Scrums (SoS) meeting. The SoS helps coordinate the dependencies of the ARTs and provides visibility into progress and impediments. The RTE, Scrum Masters, and others (where appropriate) meet to review their progress toward milestones, program PI objectives, and internal dependencies among the teams. The meeting is timeboxed for less than 30 minutes and is followed by a ‘meet after’ to solve any problems that emerge during the SoS. A suggested agenda for the SoS meeting is described in Figure 3.
Similar to the SoS, a PO sync meeting is often held for POs and Product Managers. This meeting typically occurs weekly, or more frequently, as needed. The PO sync is also timeboxed (30–60 minutes) and is followed by a ‘meet after’ to solve any problems.
The PO sync may be facilitated by the RTE or Product Manager. The purpose is to get visibility into how well the ART is progressing toward meeting the program PI objectives, to discuss problems or opportunities with Feature development, and to assess any scope adjustments. The meeting may also be used to prepare for the next PI (discussed later in this chapter) and may include Program Backlog refinement and Weighted Shortest Job First (WSJF) prioritization before the next PI planning meeting.
Note: As shown in Figure 2, sometimes the SoS and the PO sync are combined into one meeting, often referred to as an ART sync.
Release management meetings provide governance for any upcoming releases, as well as communication to management. To learn more, read the Release on Demand chapter.
A system demo is a biweekly event that provides feedback from the stakeholders about the effectiveness and usability of the system under development. This demo also helps ensure that integration between teams on the same ART occurs on a regular basis, no less frequently than every iteration. Given that “integration points control product development [1],” the PI is the routine point at which the meaningful, emergent behavior of the full system or solution can be evaluated.
While we note this function as an event in Figure 3, preparing for the upcoming PI is actually a continuous process, with three primary focus areas:
Management alignment and organizational readiness for planning
Backlog readiness
The actual logistics for the event—for example, facility readiness
Since any one of these factors can interfere with the desired outcome—that is, a specific and committed PI plan—careful consideration of all three factors is necessary.
The PI is done when its timebox expires. Each PI is followed by a final system demo, a newsworthy event that illustrates all the Features that have been accomplished during the PI. This demo is usually done as part of the I&A workshop, which offers a regularly scheduled time to reflect, problem-solve, and take on improvement actions needed to increase the velocity, quality, and reliability of the next PI. The result of the workshop is a set of improvement backlog features or Stories that can be added to the backlog for the upcoming PI planning. In this way, every ART improves every PI.
The Large Solution Level has additional important events and activities, which bring a similar focus to the progress of the solution. These events and activities are described next.
Pre- and Post-PI Planning events are used for preparation and coordination of PI planning across multiple ARTs and Suppliers in a Solution Train. The purpose of these events is to create a common Vision and mission as well as a set of features that will advance the solution in alignment.
The pre-PI planning event is used to coordinate input (e.g., objectives, key milestones, business context, and Solution Context) for the ART planning sessions. The post-PI planning event is used to integrate the results from individual ART planning sessions into the vision and Roadmap for the Solution Train. At the end of the post-PI planning meeting, there should be an agreed set of solution PI objectives that are expected to be implemented by the end of the PI and demoed at the next solution demo.
During the PI timebox, the ARTs build multiple increments of value, which grow into solution Capabilities. The new capabilities must be designed, developed, tested, and validated holistically, along with the existing capabilities of the system. The solution demo is a critical aspect of the PI learning cycle. This high-profile event allows large solution stakeholders, Customers (or their internal proxies), and senior management to view the progress that the solution has made during the past PI.
At this event, the Solution Train demos its accomplishments for the entire PI. Senior managers and stakeholders review the progress in the broader solution context. It may also inform decisions about whether to pivot or persevere with capabilities, as well as whether to change the Lean Budgets for the various Value Streams.
At the end of the PI, an additional I&A workshop may be required for the Solution Train. It follows the same format as the ART I&A. Due to the number of people involved, the Solution I&A workshop cannot include all stakeholders from the ARTs, so the most appropriate representatives are selected to address that context. This group includes the primary stakeholders of the Solution Train, as well as representatives from the various ARTs and suppliers.
LEARN MORE
[1] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.
