Short-term wins help build necessary momentum.

—Kotter

Prepare for ART Launch


This is article eight in the SAFe® Implementation Roadmap series. Click here to view the entire roadmap.


Previous articles in the SAFe Implementation Roadmap series discussed the first seven ‘critical moves’ in an implementation:

The enterprise has now identified its value streams and established an implementation plan. It will also have loosely defined the first ART. This is a pivotal moment, as plans are now moving toward implementation. From a change-management perspective, launching the first ART is a critical activity with potentially far-reaching implications. This will be the first material change to the way of working and will generate the initial short-term wins that help the enterprise build momentum. This article describes the activities necessary to prepare for the ART launch.

Details

Now is the time to execute the activities necessary for a successful ART launch. SPCs often lead the implementation of the initial ARTs, supported by SAFe-trained ART stakeholders and members of the Lean-Agile Center of Excellence (LACE).

No matter who leads, the more significant activities in preparing for the launch include the following:

  • Define the ART
  • Set the ART launch date and cadence calendar
  • Train ART leaders and stakeholders
  • Form Agile teams
  • Train Product Managers and Product Owners
  • Train Scrum Masters/Team Coaches
  • Train System Architects
  • Assess and evolve launch readiness
  • Prepare the ART backlog

Each of these activities is described in the sections below.

Define the ART

In Create the Implementation Plan, the stakeholders used to identify the first value stream and ART were detailed. At that planning stage, the ART is defined with just enough detail to determine that it’s a potential ART. However, the parameters and boundaries of the ART are left to those who better understand the local context, as shown in Figure 1.

Figure 1. Agile Release Train Canvas.
Figure 1. Agile Release Train Canvas

A vital benefit of the canvas is to help teams identify the principal ART roles. ARTs work only when the right people are given the right blend of responsibilities. After all, the ART organization is a system that must be in flow. All the necessary responsibilities of solution definition, building, validation, and deployment must be realized for the system to function smoothly. Filling in the critical roles on the canvas fosters these discussions and highlights the new responsibilities.


Special care must be taken to understand who the Business Owners are. They may include internal and external customers and/or their Product Management proxies. “Applying systems thinking,” however, means that others should often be included, for example, leaders and executives of associated value stream business areas, data center managers, enterprise and security architects, marketing and sales representatives, and whoever else has the need, scope, and authority to steer the ART. Only the right set of Business Owners can collectively align differing organizational responsibilities and perspectives.


Set the ART Launch Date and Cadence Calendar

With the ART definition in hand, the next step is to set a date for the first PI Planning event. This creates a forcing function, a ‘date-certain’ deadline for the launch, which will create a starting point and define the planning timeline.

The first step is establishing the ART cadence, including the PI and iteration lengths. The SAFe Big Picture shows a 5 iteration PI, which consists of four regular two-week iterations and one Innovation and Planning (IP) iteration. There is no fixed rule for the PI cadence nor for how much time should be reserved for the IP iteration. The recommended duration of a PI is between 8 to 12 weeks, with a bias toward the shorter period (10 weeks, for example). Once the cadence is chosen, it should remain stable and not arbitrarily change from one PI to another. This allows the ART to have a predictable rhythm and velocity. The fixed cadence also allows a full year of events to be scheduled on people’s calendars. The PI calendar usually includes the following activities:

For in-person planning, this advance notice reduces travel and facility costs. For remote or hybrid planning, it helps ensure that most stakeholders will be able to participate. Once the calendar is set, team events can also be scheduled, with each team defining the time and place for their events, including team planning, demos, and retrospectives. All teams on the train should use the same iteration start and end dates, facilitating synchronization across the ART.

Train ART Leaders and Stakeholders

Depending on the scope and timing of the rollout, there may be several ART leaders (Release Train Engineer, Product Managers, System Architects) and stakeholders (Business Owners, managers, internal suppliers, operations, and so on) who have not attended a Leading SAFe training session. They will likely be unfamiliar with SAFe, unclear on expectations, and may need help understanding the need and benefits of their participation. They must understand and support the model and the responsibilities of their role. In that case, SPCs will often arrange a Leading SAFe class to educate these stakeholders and motivate participation. This is usually followed by a one-day implementation workshop, where newly trained stakeholders and SPCs can create the specifics of the launch plan. After all, it’s their ART; only they can plan for the best outcomes. Essentially, this is the handoff of primary responsibility for the change from the change agents to the stakeholders of the newly formed ART.

Form Agile Teams

The next step is to form the Agile teams that will be on the train. One solution is to enable the people on the ART to organize themselves into Agile teams with minimal constraints. In other cases, management makes initial selections based on their objectives, knowledge of individual talents and aspirations, timing, and other factors. In most cases, a bit of back and forth between management and the teams will be needed. Teams better understand their local context and know how they like to work. Managers add perspective based on current individual, organizational, and product development strategies.

Before PI planning, all practitioners must be part of a cross-functional Agile team, and the initial roles of Scrum Master/Team Coach and Product Owner must also be established.

The example team roster template shown in Figure 2 is a simple tool that can help bring clarity and visibility to the organization of each team.

Figure 2. An Agile team roster template
Figure 2. An Agile team roster template

The simple act of filling out the roster can be quite informative, as it makes the more abstract concepts of Agile development concrete. After all, the structure of an Agile team is well defined; the question of who is on the team, and the nature of the specialty roles, can lead to interesting discussions. Even the seemingly simple act of dedicating an individual to one Agile team can be an eye-opening experience. But there’s no going back. The proven success patterns of Agile, including ‘one person–one team,’ are clear.

The geographic location column is also interesting, as it defines each team’s collocation and distribution level. That may evolve, but at least everyone understands where the current team members reside, so they can start thinking about time zones for Team Sync times and other team events. It can also be helpful to include the name and contact information of the direct supervisors for each member of the ART. This helps ensure proactive communication and coordination with managers before changes are announced (they should also be invited to attend Leading SAFe!).

Organizing Agile Teams with Team Topologies

Good Agile team design is one of the main contributing factors to the success of the ART in meeting its goal of continuously delivering value to the customer. Regardless of whether the ART is organized around value, if the teams on that ART remain siloed, then it will need help to meet this goal.

To help with this, SAFe recognizes four team topologies from the work of Mathew Skelton and Manuel Pais [1]. These four fundamental teams types enhance and simplify this task of organizing around value:

  • Stream-aligned teams are end customer-aligned and are capable of performing all the steps needed to build end-to-end customer value.
  • Complicated subsystem teams are organized around critical solution subsystems. They focus on areas of high technical specialization, which limits the cognitive load on all the teams.
  • Platform teams provide application services and APIs for stream-aligned teams to leverage common platform services.
  • Enabling teams provides tools, services, and short-term expertise to other teams.

The Agile Release Train article provides further information on each team topology, when to apply them, and their associated behaviors and responsibilities.

Train Product Owners and Product Managers

Product Managers and Product Owners steer the train together. They have the responsibility and authority over features and stories, respectively. These two roles are critical to the success of the ART, and the people fulfilling these roles must be trained to ensure optimal collaboration, learn the new way of working, and understand how to fulfill their specific responsibilities best. In addition, these roles will be primarily responsible for building the initial ART backlog, which is a crucial artifact for PI planning.

Scaled Agile, Inc.’s two-day SAFe Product Owner/Product Manager course is designed specifically for this purpose. The course teaches Product Owners and Product (and Solution) Managers how to drive value delivery in the SAFe enterprise. Attendees get an overview of SAFe’s Lean-Agile Mindset and principles and an in-depth exploration of role-specific practices. Attendees learn how to write Epics, Features, and User Stories, and establish the Agile Team and ART backlogs to manage and improve their flow.

Train the Scrum Masters/Team Coaches

Effective ARTs primarily rely on the servant leadership of the Scrum Master/Team Coach and their ability to coach Agile Team members and improve the team’s performance. It’s a specialty role that includes traditional Scrum leadership duties, new responsibilities to help the teams achieve flow, and responsibilities to the larger team-of-Agile teams that constitute the ART. Scrum Masters/Team Coaches also play a critical role in PI planning and help coordinate value delivery through Coach Sync events. It’s incredibly helpful if they receive appropriate training before starting the first PI.

Scaled Agile, Inc.’s two-day SAFe® Scrum Master course teaches Agile Team coaching fundamentals and explores a team’s role in the context of SAFe. It prepares Scrum Masters/Team Coaches for how to facilitate team events, successfully plan and execute the PI, participate in ART events, and measure and improve the flow of work through the system using Kanban. This course benefits new and experienced Scrum Masters/Team Coaches.

Train the Architects

Architects enable solution development by providing, communicating, and evolving the solution’s broader technology and architectural view. In so doing, they enable Agile teams to make effective, decentralized decisions that accelerate the creation of business value while ensuring that the solution’s architecture remains robust and sustainable. Individuals fulfilling these roles must be experienced technical experts and influential Lean-Agile Leaders skilled at engaging across the organization. Partnering with Product Management and the RTE, System, and Solution Architects define enabler features in the backlog designed to maintain the architectural runway necessary to sustain business value creation.

Scaled Agile, Inc.’s three-day SAFe for Architects course teaches senior technical contributors the role of architecture in a Lean-Agile enterprise. Attendees will explore the principles underlying Lean-Agile architecture and release on demand, learn to lead and support Solution Trains and Agile Release Trains, extend the principles driving continuous flow to large systems of systems, and discover how to enable an improved flow of value across an entire portfolio.

Assess and Evolve Launch Readiness

Training people in their new roles and responsibilities is a vital part of ART readiness, but it’s only one element of a successful ART launch. Additional activities are required. However, since SAFe is based on the empirical Plan-Do-Check-Adjust (PDCA) model, there is no such thing as perfect readiness for a launch. Even attempting to achieve such a state is a fool’s errand, as the experience of the first PI will inform future activities. What’s more, trying to be too perfect up-front will delay learning, postponing the transformation and realization of its benefits.

That said, a certain degree of readiness will help assure a more successful planning event the first time. Figures 3 and 4 provide a checklist for ART readiness assessments and activities.

Figure 3. ART readiness checklist: needed items
Figure 3. ART readiness checklist: needed items
Figure 4. ART readiness checklist: desirable items
Figure 4. ART readiness checklist: desirable items

Most would agree that most of the items in Figure 3 are required for a successful launch. The things in Figure 4 are undoubtedly desirable, but depending on circumstances, they can also be addressed over the first few PIs.

Prepare the ART Backlog

As previously mentioned, using the launch date as a forcing function increases the urgency of determining the scope and Vision for the PI. After all, no one wants to show up at PI planning without a solid sense of the mission. While it’s tempting to assume that should be the case before the event, experience often shows otherwise. It’s more likely that there will be multiple opinions about what the new system is supposed to do, and it might take some time to converge those points of view before the launch date.

The scope of the PI, or ‘what gets built,’ is primarily defined by the ART Backlog, which contains the set of upcoming features, NFRs, and architectural work that define the system’s future behavior. To that end, SPCs and LACE stakeholders often facilitate bringing the ART stakeholders together to prepare a common backlog. This is typically done in a series of backlog refinement workshops and other activities, as illustrated in the example preparation timeline shown in Figure 5.

Figure 5. Preparing the ART backlog and related activities.
Figure 5. Preparing the ART backlog and related activities

It’s easy to over-invest in backlog readiness, so don’t let that bog the process down, as the act of planning with the teams will sort out many issues. Experience shows that a list of well-written features with initial acceptance criteria is sufficient. Many tend to over-plan and create user stories ahead of time. But that tends to create waste and disappointment when the vision changes.

Moving Forward

So far, it’s been quite a journey. Here’s what has been accomplished so far:

  • Reached the tipping point
  • Trained Lean-Agile change agents
  • Created a Lean-Agile Center of Excellence
  • Trained executives, managers, and leaders
  • Prepared to Lead in the Digital Age
  • Organized around value
  • Created the implementation plan
  • Prepared for the first ART launch

It’s finally time to leave the station and launch this train! For more on the launch events, read the following article in this series, Train Teams and Launch the ART.

This article serves as a launching pad to explore these steps in detail and understand how to apply them to specific implementations.


Learn More

[1] Skelton, Matthew, and Manuel Pais. Team Topologies. IT Revolution Press, 2019.

SPC toolkits

Additional Resources

Last update: 16 February 2023