SAFe® In a Nutshell – PI Execution

In our last installment, we covered how to prepare for a PI Planning event and the roles involved, including those of the technical authority, content authority, and execution authority. In this installment, we’ll describe PI execution in SAFe® and the recommended sequence of events that follow a PI planning.

(Looking to first understand how SAFe® works at its core? Check out this blog then come back.) 

Ceremonies

Scrum of Scrums

The main purpose of the Scrum of Scrums, which is driven by the Agile Release Train (ART) Execution Authority (i.e. the Release Train Engineer (RTE)), is essentially to ensure that the team is on track with the committed plan that was drafted in PI planning. The plan, reflected on a physical program board during PI planning, should be an artifact that is transferred into your tool, such as Jira Align, so teams can continually reference it throughout the PI.

(Image Source)You can view the Scrum of Scrums as a series of ‘mini commitments’ that enable the team to make progress. During this ceremony, we seek to understand:

• Are you on track in the current iteration as well as the PI overall?
• What obstacles are standing in your way?
• What dependencies have been satisfied for other teams?
• Have other teams satisfied your dependencies?
• Are there any issues that would require help from the RTE?
• Are there any scope adjustments you think you need to request from the Content Authority to address issues or risks?

During the Scrum of Scrums, your teams may come to the realization that they need to make scope adjustments due to unmet dependencies or technical issues. In this case, the team may submit a request to deprioritize certain objectives or associated features in order to satisfy higher priority objectives. The RTE can then take this request to the PO Sync, or meet with the product management team to discuss further and seek final approval.

A key point to remember is that teams should not only focus on features, but on objectives. Having this in mind can help drive additional conversations on scope changes, for example in the case where your teams realize an objective can actually be satisfied without doing all the planned work – saving both time and resources.

 

PO Sync

The PO Sync, driven by the ART Content Authority (i.e. the Product Management Team), is typically for Product Owners and Product Management, but also generally includes the RTE as well as the System Architect and Business Owner for some of the relevant topics. While there will generally be some discussion on the current PI, this event should be primarily focused on the future and getting the next set of features ready for the next PI.

Activities involved in the PO Sync involve:

• Resolving issues in the current PI – This can include scope adjustments that are identified during the Scrum of Scrums. This should ideally make up a very small part of the PO sync.
• Resetting your roadmap – Teams may need to reprioritize due to market changes, learnings from your last Inspect and Adapt session, etc. This is typically done very early in the PI in order to validate the set of Features that should be the priority to get ready for the next PI.
• Feature refinements – The aim of this activity is to get features to a “PI ready” state heading into the next session. Teams can leverage product thinking and/or product management tools like personas and journey maps, along with other customer centricity activities, in order to ensure that backlog refinements align to customer needs.

Check out this webinar on how to get from an idea to an actionable backlog.

 

Architect Sync

An additional event that we’d like to include here is the Architect Sync. This is currently referenced in SAFe® only at the Large Solution level as an event that may be needed on a solution train to sync with the architects across the various trains. But, we’d suggest that this ceremony is very valuable even at the release train level.

The Architect Sync would be driven by the System Architect as the ART Technical Authority and would include tech leads or key subject matter experts from the teams who would meet with the architect on a regular basis.

This sync would ideally focus most on:

• The Architecture Runway – Define enablers that would help inform and build the architecture runway so that the train is then able to deliver business value oriented features that the product management team is looking for.
• Technical guardrails for the teams – The goal for architects in SAFe is to drive “Intentional Architecture,” which provides the guidance and standards, or the “guardrails”, for the teams so that they can still practice emergent design as they design their features and associated stories. This strikes the proper balance between centralized and decentralized architecture and design.

Again, while this event is not formally mentioned at the release train level such as the Scrum of Scrums and the PO Sync, we highly recommend that you look to implement this ceremony as well.

 

System Demo

Another critical event in PI execution is the System Demo, driven primarily by the System Team who is responsible for helping the teams on the ART integrate their work early and often. This event serves to demonstrate integration and actual end to end functionality of features and delivery of objectives throughout the PI, as opposed to waiting until the end.

During this event, the system team demonstrates interim functionality that has been integrated and tested since the teams delivered their last iteration. The business owner, product management team, and key stakeholders should all be present in order to provide feedback (and approval, given that the team has met the success criteria for features.)

 

Ceremony Cadence

In terms of frequency of each ceremony, while dependent on the complexity of your team, a suggested outline could be:

• Scrum of Scrums: 2x a week, on a Tuesday and Thursday
• PO Sync: 1x a week, on a Wednesday
• Architect Sync: 1x a week, on Thursday (after the Scrum of Scrums on Thursday)
• System Demo: 1x every two weeks, after the end of each iteration, no more than one iteration behind the teams

In the above cadence, the first Scrum of Scrums on Tuesday can inform the PO Sync on Wednesday. The outcome of those discussions could then be discussed in the second Scrum of Scrums on Thursday. The output of the PO sync may also drive some discussion in the architect sync on Thursday.

You can experiment with the cadence; ideally, it should facilitate exchange of information and coordination among the ceremonies.

 

What Happens Next?

Now that we’ve covered PI planning (the “plan”) and PI execution in SAFe® (the “do”), along with the System Demo (the “check”), the final step in the cycle is “adjust” – which is achieved through the Inspect and Adapt workshop (I&A).

Stay tuned for the next installment in this blog series where we’ll explore the I&A in further detail.