SAFe 5: PI Execution
Summary
- Additional governance is required to plan, and coordinate the execution of Program Increments.
- A dedicated role to support PI execution processes – Release Train Engineer (RTE) ensures delivery teams are not distracted from delivery tasks.
- With appropriate instrumentation, execution progress can be measured, so that timely adaptation can be applied when necessary.
Definitions
- Portfolio: A collection of programs (that realize products or services, from which an organization gets revenue).
- Program Backlog: Ranked list of features for a given program increment.
- PI: Program Increment – The basis of the SAFe cadence-based delivery model. Typically 10-12 weeks (5-6 sprints). Big enough so that substantial objectives can be accomplished, small enough to enable inspection and adaptation of the delivery model.
- Agile Release Train (ART): A set of orchestration mechanisms to synchronize the work of multiple teams to produce releasable product increments on a fixed cadence.
Agile Release Trains (ARTs)
- An ART is an organizational arrangement to synchronize the activities of multiple development teams building software from a single program backlog to support a single product or value stream.
- Optimized for 5-12 teams (50-125 people)
- Operate on fixed-length timeboxes. Default is 10 weeks (5 iterations)
- Product Manager (‘Chief PO’) owns the Program Backlog and feature priorities
- A Program Backlog is mostly a list of features, but can contain other items such as higher level business objectives, milestones (e.g. trade show event), and ‘enablers’ (infrastructure upgrades, architectural enhancements).
- Architects for dependencies and interfaces
- Teams own story creation and estimates
- Features fit in a single PI, and are implemented incrementally via user stories
- Teams operate in synchronized cadence
ART Roles
- Release Train Engineer (RTE) – ‘Chief Scrum Master’ – orchestrates all ART events
- Product Manager – ‘Chief Product Owner’ – owns & prioritizes the Program Backlog
- System Architect – Owns definition of overall technical solution
- Teams – Own PI Planning and feature delivery.
- Development Management – plays a supportive role. Works to eliminate impediments that are beyond the control of the teams, actively supports teams with training, tooling and any other support needed for success.
- Business Stakeholders – Ensure programs are aligned with strategic themes and roadmap. Actively participate in program-level events.
ART Events
- PI Planning Preparation – Feature intake, refinement and ranking
- PI Planning – Align on objectives for next program increment. Estimate feature scope. Frequency: 2 days, every 10 weeks. (Alternative approaches are possible, especially for distributed teams).
- Scrum-of-Scrums – an Inspect & Adapt event for teams to maintain synchronization and alignment during the PI execution – frequency is from daily to at least weekly.
- ART Sync. An event where ART stakeholders see progress, help resolve impediments, and agree on any needed adjustments to the baseline PI Plan.
- System Demos – end-to-end demo of integrated work from all teams at end of each iteration.
- PI Demo – demo of all completed PI Objectives upon completion of each PI.
- PI Retrospective – retro on completion of PI objectives.
ART Artifacts
As PI execution proceeds, problems of many kinds will be encountered. Sufficient data is needed to regularly assess progress and determine if adjustments to the baseline plan are needed. At minimum the following 3 artifacts are needed to help guide the program through execution.
- Actively maintained program wall-board. (Physical or electronic)
- Feature completion reports.
- PI burn-up chart – story points (or just stories) completed by iteration.
For those that have the luxury of a dedicated physical space for their Scrum-of-Scrums, have all 3 of these charts on display for the program team. These information radiators will bring transparency and focus these events, and ensure a high degree of alignment.
ART Governance
The word governance seems out of place in any conversation about agility, and of course additional governance should be kept to the absolute minimum. Agile delivery programs do need some basic support as opposed to management and control. With multiple delivery teams collaborating on a common set of objectives some level of coordination will be required. Self-organized teams with clear missions and program objectives do not need to be managed in the traditional PMO sense. However, support is needed to coordinate and facilitate planning and execution activities. The RTE role is designed to provide this kind of support. Basic duties would include: facilitation of planning processes, scrum-of-scrums and ART Syncs, data collection, progress reporting, impediment management, and communication to keep everyone informed and aligned.
Two basic governance events are needed to support PI execution:
- Scrum-of-Scrums: This is an event to Inspect & Adapt the PI Plan. The Program Board is one way to visualize this plan, and should be used as input. Teams raise any issues impacting their contribution to the PI delivery plan, or risks to other teams such as dependencies. Some issues, for example scope changes, may require escalation beyond the teams.
- ART Sync: An Inspect & Adapt event to review overall program progress. Teams and stakeholders review overall progress, and help with escalated impediments or risks. The ART and stakeholders align on any necessary adjustments in scope or priorities.
A Release Train Engineer (RTE) coordinates and facilitates all program level events and processes including PI Planning, ART Syncs, and scrum-of scrums.
| Scrum-of-Scrums | ART Sync |
|---|---|
|
|
Organizations should experiment with the frequency and content of these events in order to get maximum benefit while keeping overhead to a minimum. Focus first on identifying the few critical measures necessary to support events like Scrum-of-Scrums and ART Sync reviews – it is important to supply these events with actionable data.
The output of every iteration is an integrated, production-quality increment of the product. The decision to release is driven by business needs. (Produce on cadence, release on demand).
What to Measure
During execution we need to continuously measure progress in order to confirm that the plan is on track to meet its objectives, or if adjustments need to be made to the plan. Without the ability to adapt we become hostage to events that inevitably emerge in the course of execution. Sound adaptation requires data, and given our planning approach, we now have the basic data to help with this task. There are 2 basic things we need to measure:
- Feature Completion Progress
- PI Execution Progress
This data is simply an extension of the basic worksheet we used in planning with a couple of extra columns to collect data on the number of done stories (and done points) per feature:
Another example of how to represent feature delivery progress:
We also need a way to confirm if we are on the right trajectory to complete all of the planned work for the PI. For this a simple burn-up chart showing points done per sprint versus total planned. (Done stories would serve almost equally well).
The chart in this example suggests that the team is behind plan (done points = 130 vs. an ideal of 160), and heading into the final sprint (where they will be operating with reduced velocity due to planning activities for the next cycle). It would be worth taking a hard look at the list of unfinished features and deciding which ones could be taken to 100% done in the next sprint and which ones should be dropped or deferred. It’s better to finish with 5 completely done features, than with 6 partially done ones. These 2 charts provide all of the information needed to help make the most sound decisions.
We also want to see how the overall PI is progressing. For this we use a PI burn-up chart, which shows completed story points by sprint: (we can roll-up the same team data to get the full picture):
The chart in this example is likely to prompt a deeper dive into feature-level detail.
Agility is built on the foundational pillars of Transparency, Inspection and Adaptation. These are prerequisites for empirical operation and having the ability to course-correct based on facts and data. Agility at scale is no different, and successful delivery using SAFe, needs to be driven by continuous measurement and adjustment with the goal of maximizing the output of value.
Recommended Reading: SAFe PI Planning: A Step-By-Step Guide
