Agile Scaling: SAFe Best Practices for Scrum Masters

This article is part two of Toptal’s Agile scaling series, designed to guide project managers in their team expansion efforts. Read the first installment, “5 Agile Scaling Frameworks Compared: Which One Should You Use?” for an in-depth overview of the most popular options. In the final article in this series, “SAFe Case Studies: Transformation Notes From the Field,” Toptal experts and SAFe inventor Dean Leffingwell discuss scaled transitions.

As products grow and become more complex, so do the teams that produce them. When it’s time to scale, many companies transition from Scrum to the Scaled Agile Framework (SAFe), a system that’s implemented at the enterprise level and allows businesses to manage multiple, complex products that require teams of teams to develop.

A Scrum master moving into a SAFe framework will step into an environment that is at once familiar and new. The artifacts, roles, and ceremonies are based on Scrum. But operating at a higher scale comes with some additional responsibilities, especially for Scrum masters who opt to move into the role of a release train engineer (RTE), a common trajectory. The RTE acts as the Scrum master of the entire release train. Instead of leading a Scrum team of nine to 11 people, RTEs become servant-leaders to teams of teams that straddle multiple departments, and they organize events of greater size and scope.

The Basics: Scrum to SAFe

SAFe allows a company to apply Agile approaches, values, and principles across multiple teams. The resulting “team of teams” is known as the agile release train (ART). Individual teams continue to employ a Scrum master to do business as usual, while the Scrum master-like role on an ART is done by an RTE. The RTE applies the general mechanisms and governance of Scrum but at an organizational, rather than team, level. Other traditional team-level Scrum roles and artifacts change accordingly, too. For example, the ART “product owner” becomes a product manager; a “product backlog” becomes the program backlog; a “sprint backlog” is an iteration backlog; and the “product increment” is now the program increment (PI).

There are four configurations of SAFe—Essential, Large Solution, Portfolio, and Full—and the one you use depends on how extensively your company adopts the framework. The configurations allow implementation at multiple levels, ranging from several teams working together to full portfolio integration and enterprisewide business agility. But at every level, the goal remains to scale Agile and Scrum practices, not replace them.

Scrum Masters in SAFe

Scrum masters working in a SAFe framework at the team level will find that their jobs are not significantly different. They will remain a servant-leader for an Agile team, responsible for coaching and education, removing impediments, and fostering an environment where team members feel safe to perform their best and continuously improve.

However, there will be some new responsibilities. A SAFe Scrum master supports the RTE in the PI planning event and in program execution, and represents their team in ART sync meetings. When there are impediments that are beyond the team’s capability to remove, the Scrum master escalates them to the RTE.

A Scrum master who decides to become an RTE will find that their role comes with decidedly more considerations. The ART may include teams that are new to you or new to Agile, like business analysis, hardware, or compliance. And because the higher configurations of SAFe include program or portfolio operations, management will be directly and regularly involved in ways they would not be in Scrum, making sure everything is aligned with enterprise- and/or portfolio-level goals.

The RTE is responsible for removing impediments that are beyond a single team’s capacity. They communicate with stakeholders and drive continuous improvement at the ART level. The RTE coaches not only teams but also the leaders of those teams, helping all levels of the ART move toward self-organization and self-management.

SAFe Events

Just as a Scrum master facilitates team-level events, an RTE facilitates ART-level events—the PI planning, the ART sync, the system demo, and the inspect and adapt. As an RTE, you’ll be engaging with a wider variety of stakeholders than you were as a Scrum master and handling multiple teams with competing interests. There are more—and more varied—attendees at every event, and you need to align priorities and get buy-in for initiatives well in advance.

PI Planning

The PI planning event is an essential ceremony for SAFe, a gigantic two-day session to align the goals of all teams within the ART for the next eight to 12 weeks by creating the PI plan. It’s like a sprint planning event, but it spans multiple sprints across multiple teams.

Inputs

• Business vision
• List of top 10 to 15 features to be implemented
• Details on each team’s capacity

Outputs

• PI plan (a delivery plan for the next five to six sprints)
• PI objectives
• List of potential risks

General Tips for the PI Planning Event

• Obtain stakeholder buy-in. Prior to the meeting, RTEs should establish who the key stakeholders are and share their inputs with the group.
• Align priorities. Before the session, schedule a daylong meeting with the product management team to agree on a high-level view of what features should be delivered, as well as future priorities. There will be plenty to work out at the event, like risks and dependencies, and it’s good to have basic directional agreement in place.
• Rehearse! The PI planning is a huge event. It might not be useful to spend two full days rehearsing, but a two- to four-hour session with the ART’s team leaders that creates an as-close-as-possible experience will help immensely. Create a simplified version of the event’s agenda and share it prior to the rehearsal so that practice can start from a well-informed place.
• Be prepared for mission creep. The goal of the PI planning is to deliver a long-term plan in a comparatively short period of time. Sometimes people will want to go into extensive detail on everything, which is not what the event is for. Explain this to the team leaders at the rehearsal and in the session; remind the teams that the aim is to deliver high-level plans and create alignment, not to plan every minute of the next three months.
• Prepare team-capacity information. Ask your Scrum masters to provide capacity calculations for the next eight to 12 weeks. Expect some pushback or questions; for instance, a Scrum master may not know precisely how many absences their team will have over the next two months. In such cases, ask for estimates, and be flexible when responding to capacity limits during the PI itself.
• Share the PI planning agenda. Distribute the schedule at least two weeks before the event, and be prepared to answer a lot of questions. There will be many attendees, and if SAFe is new to you and your company, it’s probably also new to many other team members. In my experience, by the second or third PI planning event, the pressure on the facilitators becomes much less intense as the teams get familiar with the event and know what to expect.
• Secure management attendance. It’s often difficult for managers or senior managers to attend a two-day event, but management attendance is a must to ensure high-level alignment. Confirm their attendance at least two weeks before the PI planning, and arrange for any support they’ll require. The same applies to business owners, who need to sign off on PI objectives.

ART Sync

The ART sync event is a weekly meeting where the RTE can gain insights into the teams’ progress and identify program risks and roadblocks. While by no means the only occasion for an RTE to evaluate impediments and determine whether they require escalation, it’s an important event that provides a regular venue for these matters to be raised.

Inputs

• Teams’ progress
• Impediments log
• The PI plan (to identify any major deviations between the plan and actual progress)

Outputs

• Escalations (if required)
• Decisions about any changes to the PI plan

General Tips for the ART Sync Event

• Encourage regular communication. Because the ART Sync is weekly, instead of daily like Scrum stand-ups, the RTE should make it clear that teams can raise urgent issues immediately and shouldn’t wait for the next ART sync.
• Be prepared with data. Ask Scrum masters and product owners to bring quantifiable progress metrics, such as burndown or cumulative flow, in order to have an informed conversation about progress.
• Go beyond a weekly status review. The ART sync is meant to be an event where priorities are aligned and problems are resolved, not a simple check-in.

System Demo

The system demo is intended to showcase the full scope of work created during a preceding iteration. At this event, the product manager and their team show business owners and other stakeholders the ART’s integrated progress in its current form.

Input

• The current state of work based on the output of all Agile team members over the course of the preceding iteration

Outputs

• Feedback on the system’s fitness for purpose
• Changes to the backlog (if required)

General Tips for the System Demo Event

• Rehearse! Devote 30 to 45 minutes every other week to working with presenters to nail down their segments.
• Ditch the slides. Present the actual integrated work. If you’re working on a software product, have the presenters show the stakeholders a working product increment rather than a slide deck. If possible, demonstrate your product in a staging environment. You want the demo to accurately resemble the end-user experience. If you are unable to present an integrated system every two weeks, look at your delivery pipeline and brainstorm with the teams on how you can adopt CI/CD and DevOps culture.
• Focus on business value. Your presentation is for business owners and stakeholders; share what’s most important to them.
• Keep the feedback focused. The stakeholder feedback you receive will be important, but this event is not the time for drastic changes to the product vision or roadmap. Be ready to steer the conversation back to high-level feedback that the teams can turn into action items at a later time.
• Keep it short. Stakeholders are busy people; a 45- to 60-minute meeting will result in more frequent and engaged attendance.
• Allow time for Q&A. Be transparent in your answers. Remember that sometimes “I don’t know, but we can find out” is the best answer.

Inspect and Adapt

The inspect and adapt is a mega-retrospective session that takes place at the end of a PI. The session is divided into three parts:

• The PI system demo: a showcase for the entire PI’s integrated output. It’s similar to the main system demo, but instead of one iteration, this event showcases the integrated work across the entire PI.
• Quantitative and qualitative measurements: an opportunity for the RTE to present metrics gathered over the course of the PI. These metrics include (but are not limited to) team velocity, user stories accepted, unit test coverage, or open defects.
• Retrospective and problem-solving workshop: a chance for participants to look back on the PI, reflect on what did and did not work, identify systematic issues, and propose ways to resolve them.

Inputs

• Teams’ progress
• The current state of the ART’s integrated work, including all of the program increment’s output

Output

• List of potential improvements

General Tips for the Inspect and Adapt Event

• Give business owners advance notice. Provide at least two weeks’ notice before the event. Meet with any attending product managers and business owners before the session to align on the qualitative results presentation.
• Secure the attendance of senior stakeholders. Their presence is most important at the PI system demo when you showcase the team’s work and the evolving product. Many of the pointers for the regular system demo apply here: rehearse beforehand, avoid presentation slides, and showcase actual deliverables.
• Avoid blame. Throughout the session, make sure that nobody feels threatened by the data presented or the problems identified in the retrospective. Some teams may feel jealous or defensive if another team’s numbers are higher or feel singled out if a problem originated with their team. Embrace a whole-team culture to preempt such problems.
• Focus on systematic issues. Try not to give too much attention to sporadic problems, provide your team with the space they need to brainstorm, and let imaginations run free for the proposed solutions.
• Create actionable proposals. At the end of the event, you should have backlog items for the teams to implement. Identifying problems doesn’t help if you don’t take steps to solve them.

The table below compares the SAFe events with their Scrum equivalents, and describes the frequency and execution of ceremonies at the enterprise level:

Stepping Up and Scaling Up

The transition from Scrum to SAFe can be an intimidating one. Operating at a higher scale will always present new challenges and new ways of thinking about even the most familiar practices. If you choose to become an RTE, you’ll find that the job depends most on the skills you already have. An RTE is a change agent and a servant-leader, just like a Scrum master, and the job gives you the chance to perform this role at an enterprise level, elevating your skills alongside your products.

Read the next installment of Toptal’s Agile scaling series, “SAFe Case Studies: Transformation Notes From the Field.”