Agile Planning Horizons (And how to Select Them) – An Enterprise Guide – Part 4

Following from Parts 2 and 3 of this series which provided an overview of the Flow and Sprinting planning horizons, this article provides a closer look at the Program Increment, a Scaled Agile Planning Horizon.

Overview

Program Increment is a timebox artifact of SCALED AGILE operations. PI represents a committed Enterprise or Portfolio vision and execution plan. A PI is timebox for delivery of a Value Stream which is executed by “teams of teams” which are organized as Release Trains or Solution Trains.

• Release Train – A long-lived team of Agile teams which delivers solutions in a value stream. The Release Train operates in synchronous cadence and practices regular, organized cross-communication around blocks and dependencies
• Solution Train – An organized group of release trains that is focused on building large and complex solutions under a shared, over-arching business/technology mission.

• Source: https://d2o2utebsixu4k.cloudfront.net/media/images/1544077632343-A-Value-Stream-can-have-many-ARTs-within-it.jpg

The Program Increment (PI) itself is a series of sprints (usually 4-6 sprints) in which multiple teams operate on a shared sprint cadence to deliver on one or more committed objectives of the PI.

The PI framework is an Enterprise-level synchronization of Agile Teams to deliver on large-scale enterprise objectives. Naturally, this requires large-scale synchronization of cadence and planning ceremonies across all teams. This includes daily or weekly syncs as needed (i.e. Scrum of Scrums and/or PO sync). This isn’t a status report. Instead, it is about communicating and coordinating about blockers/impediments, dependencies and “sequence of event” needs in order to ensure results are accomplished within the PI timebox for ALL teams in the train.

By synchronizing the PI planning and the following sprints across all Teams and Trains tasked with delivery, cross-domain planning is enabled. As a result, the Scaled Agile organization benefits from:

• Structured Cadence
  • Improved predictability
  • Improved stakeholder confidence in wait times for committed capability
  • Support for regular planning and cross-functional coordination
  • Limitation of batch sizes of work to discrete intervals
  • Scheduled integration points
• Synchronized Cross-Domain Planning
  • Improved control of injection of new work
  • Improved and routine dependency management
  • Supports full-system integration and assessment
  • Multiple feedback perspectives
  • Facilitates the ability for all stakeholders to engage with each other at the same time
  • Requirements and design planning occurs in a comprehensive way
  • Important stakeholder decisions are accelerated
  • Trains and Teams create and take responsibility for the PI plans created
  • Sequences and dependencies are understood and accounted for among Trains and Teams

The PI Planning Horizon requires a focus on dependencies and sequence of execution across teams for the purpose of achieving aligned Enterprise goals. A more detailed overview of the Program Increment can be found here: [https://www.scaledagileframework.com/program-increment/]

Ceremonies

There are a number of ceremonies which typically occur within the PI:

PI Planning – PI Planning is a Scaled Agile ceremony (usually lasting 1-3 days), in which multiple teams gather to establish, plan, and commit to the objectives to be delivered collectively by the teams. Each team will create and commit to its own objectives, but these will be in alignment with an over-arching vision and roadmap. The ceremony should have a standard agenda which starts with a presentation of the business context and vision, followed by team breakouts where each team’s plans and commitments are established and presented. A more detailed overview of this ceremony can be found here: [https://www.scaledagileframework.com/pi-planning/]]

Scrum of Scrums and PO Sync – Teams should have a built-in schedule to sync every 1 or 2 weeks (or more frequently if needed) to coordinate around various team or train dependencies and review progress and impediments to make plan adjustments as needed. This sync can occur as either a Scrum of Scrums or a PO Sync, or it can be combined into a single ceremony, as appropriate.

System Demo – The system demo is held collectively at the end of each sprint among all Teams in a Train. The objective is to demonstrate the current state of the solution overall, and gather feedback from sponsors/stakeholders/customers at the “Train Level”. This ceremony should be an integrated demonstration that provides an objective measure of functionality, progress, and ultimately value of the work delivered so far within the PI. This feedback provides an opportunity for the Train to validate its progress against PI objectives and/or to make course corrections. At the end of the last sprint in the PI, there is a “Final System Demo” which is delivered in the same way, and should be a fully integrated demonstration of the functional product achieved in the PI against the committed objectives. A more detailed review of this ceremony can be found here: [https://www.scaledagileframework.com/system-demo/]

Inspect and Adapt Workshop – The Inspect and Adapt Workshop is held at the end of the PI. It should include all of the teams and stakeholders who participated in PI Planning and/or were involved in supporting the execution of the PI. This event allows the teams and stakeholders to inspect the end result of the PI and engage in collective exercises for the purpose of continuous learning and improvement. The workshop consists of three parts:

1. Final System Demo
2. Quantitative and Qualitative Assessment
3. Retrospective and Problem-Solving Workshop

A more detailed review of this ceremony can be found here: [https://www.scaledagileframework.com/inspect-and-adapt/]

Artifacts

Capability (or “Solution Capability”) – A Capability is a higher-level behavior or functionality that is identified, planned, refined, and committed for delivery by the Solution Train; typically the Solution Capability is delivered by multiple Release Trains. The Capability is composed of one or more Features and is sized to fit within the PI. Capabilities are usually created by Product Managers in collaboration with Product Owners and other key stakeholders. Capabilities are structured like features, but they are at a higher level of abstraction, describing system-level behavior and function in support of the definition and development of large solutions. Solution Capabilities comprise Strategic Solutions: the products, services and systems delivered to the customer.

Master Feature – In some Scaled Agile organizations or contexts, Master Features exist to help enterprises organize and group related Features. Master Features have the same properties as Features and Capabilities (overview, statement of benefit, and acceptance criteria) but exist at a level of abstraction higher than that of a Feature but lower than that of a Capability.

Feature – A Feature is a service or functionality that fulfills a stakeholder need.

The Feature is the primary artifact, which is identified, estimated, and groomed to “ready state”, and ultimately planned and committed to by the Release Train within the sprints of a Program Increment.

The feature should include a description of the service or function as well as a statement of benefit and acceptance criteria. The Feature is composed of one or more User Stories. Features are typically created by the Product Owner, with Solution (or System) Architects commonly creating enabler features that will be required for delivery of the functional Features and Capabilities. Features are committed to by Release Trains at the PI level, and the constituent Stories are committed to by Teams at the Sprint level.

Additional information about Features and Capabilities can be found here: https://www.scaledagileframework.com/features-and-capabilities/

Roles

Product Manager – The Product Manager is responsible for the Program backlog and roadmap, which is the definitive repository required to meet the upcoming release objectives, support strategic initiatives at the Program level, and provide the overall product vision and roadmap. The Product Manager works with Product Owners to ensure that Features being developed deliver the value and meet the needs of customers and stakeholders based on the overall PI objectives.

Release Train Engineer (RTE) – The RTE is a Scrum Master of Scrum Masters, acting at the Program level to coordinate resources, actions, planning, execution against commitments, removal of impediments, and ultimately results of multiple Scrum Teams at the Program level.

Solution Train Engineer (STE) – The STE is a Scrum Master of RTEs, acting at the Portfolio level.

Product Manager/Director – Senior product leader who understands the big picture and manages multiple Product Owners.

• Owns and manages the delivery Roadmap on a timescale of 2 or more Quarters ahead.
• Owns leadership sponsorship when newfound knowledge requires a pivot of scope or initiative, and manages the governance required.
• Engages senior leadership to establish and hold to commitments made.
• Communicates upstream, while maintaining situational awareness of tactical work in flight.

Solution Architect – Operates at senior management or executive level – ensures that the Product Manager(s) remain aligned with strategic objectives and empowers them to fulfill commitments.

• Owns the Strategic Roadmap, commitments, and delivery at the Portfolio level.
• Maintains situational awareness of Solution Trains in flight.
• Resolves organizational blocks – works with the Enterprise to surface and resolve impediments before they block workflow.

Enterprise Architect – The Enterprise Architect is responsible for the optimization of manual and automated processes into an integrated environment. They act as lead architects by directing, integrating, and facilitating the work of Solution Architects while working on the target and transition architecture.

Executive Sponsor – Leads or sponsors Portfolio-level planning, sets priorities and objectives at the Enterprise and/or Portfolio level. Confirms scope, priority, and value delivery objectives and supports teams to deliver on them.

Pros and Cons

Pros

• Well-led and capable organizations can deliver “market-wide” and “market-making” disruptive capability at rapid pace, and in a manner that can be sustained and iteratively enhanced by the enterprise.
• Establish an “Enterprise-wide” culture of sustainable achievement, technical excellence, and continuous improvement.
• Leverage institutional deep knowledge and human capital to rapidly introduce innovative and competitive capabilities, and keep the best assets of the enterprise engaged and delivering great value over a long period of time.
• Provides a framework for removing non-performers at the enterprise level.
• Provides a framework for promoting and enabling high performers at the enterprise level.

Cons

• Requires a VERY high level of leadership, organizational communication, and collaboration capability – generally across multiple “traditional” silos.
• PI Planning is a resource-intensive exercise that requires Executive-level commitment, communication/coordination, and follow-through. It requires not only a great effort for all teams, but it also requires executives to “get their hands dirty”, which tends to be one of the biggest challenges.
• All of the requirements of the Sprinting framework, PLUS:
  • Executive-level understanding and leadership of Agile practices at a “hands-on” level. Talking about this topic is usually insufficient – Executive Champions will need to get involved with their vision and support, and live up to the responsibilities they ask of their teams.
  • Leadership-level accountability, honesty, and open communications among Enterprise peers is REQUIRED. (This is a big ask for traditional leadership who are focused on controlling their own silos.)
  • Enterprise-level ability to commit and dedicate the needed resources without behaving as a “Helicopter Manager”.

Entry Criteria

The entry criteria for an organization to adopt and implement Program Increment Planning Horizon is high. The organization should have multiple teams with experience and some level of maturity operating Scrum-based Agile development. Organizations should have strong competence with the Agile roles in addition to a clear Executive Vision for what is to be delivered, including:

• Fully engaged Executive Product Leadership who is accountable for the performance and roadmap of the entire Product organization
• Teams with the ability to operate Scrum (2-6 teams with similar performance and capabilities should be required)
• ScrumMasters should be capable, fully committed, and engaged in their roles
• Product Owners should be capable, fully committed, and engaged in their roles
• Dev Teams must be capable, committed, and engaged in their roles