Short-term wins help build necessary momentum.

—Kotter

 

Prepare for ART Launch

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

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

• Reaching the Tipping Point
• Train Lean-Agile Change Agents
• Train Executives, Managers, and Leaders
• Create a Lean-Agile Center of Excellence (LACE)
• Identify Value Streams and Agile Release Trains (ARTs)
• Create the Implementation Plan

By now, the enterprise has identified their 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, the first ART is very important, 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 larger activities in preparing the launch include:

• Define the ART
• Set the launch date and cadence for the program calendar
• Train ART leaders and stakeholders
• Establish the Agile teams
• Train Product Managers and Product Owners (POs)
• Train Scrum Masters
• Train System Architects/Engineers
• Assess and evolve launch readiness
• Prepare the program backlog

Each of these activities is described in the sections below.

Define the ART

In Create the Implementation Plan, the process stakeholders used to identify the first value stream and ART were defined. At that stage of planning, 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 [1].

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

To understand who the Business Owners are, special care must be taken. Clearly, they include internal and external customers and/or their Product Management proxies. “Applying a systems view,” however, means that others should often be included as well—for example, VPs of development/technology, data center managers, enterprise and security architects, and marketing and sales executives. Only the right set of Business Owners can collectively align differing organizational responsibilities and perspectives.

Set the Launch Date and Program Calendar

With the ART definition in hand, the next step is to set the date for the first Program Increment (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 to establish the cadence for the program, including both the PI and iteration lengths. The SAFe Big Picture shows a 10-week PI, which consists of four regular 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 duration (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 program events to be scheduled on people’s calendars. The PI calendar usually includes the following activities:

• PI planning
• System Demos
• ART Sync, or individual Scrum of Scrum and PO Sync events
• Inspect and Adapt (I&A) workshop

This advance notice reduces travel and facility costs and helps assure that most of the stakeholders will be able to participate. Once the program calendar is set, team events can also be scheduled, with each team defining the time and place for their daily events, iteration planning, demos, and retrospectives. All teams on the train should use the same iteration start and end dates, which facilitates synchronization across the ART.

Train the ART Leaders and Stakeholders

Depending on the scope and timing of the rollout, there may be a number of ART leaders (Release Train Engineer, Product Managers, System Architects) and stakeholders (Business Owners, managers, internal suppliers, operations, etc.) who have not attended a Leading SAFe training session. They will likely be unfamiliar with SAFe, unclear on expectations, and may not understand the need and benefits of their participation. It’s important that they understand and support the model, as well as 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 often 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.

Organizing Agile Teams with Team Topologies

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

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

• Stream-aligned team – organized around the flow of work and has the ability to deliver value directly to the customer or end user.
• Complicated subsystem team – organized around specific subsystems that require deep specialty skills and expertise.
• Platform team – organized around the development and support of platforms that provide services to other teams.
• Enabling team – organized to assist other teams with specialized capabilities and help them become proficient in new technologies.

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

Forming the 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 have a better understanding of their local context and know how they like to work. Managers add perspective based on current individual, organizational, and product development strategies.

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

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

The simple act of filling out the roster can be quite informative, as it starts to make the more abstract concepts of Agile development concrete. After all, the structure of an Agile team is fairly 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 fairly clear.

The geographic location column is also interesting, as it defines the level of collocation and distribution for each team. Collocation is better, of course. But there may be cases where one or more individuals cannot be physically collocated with the others. That may evolve over time, but at least everyone understands where the current team members reside, so they can start thinking about Daily Stand-up (DSU) times and other team events. Many transformation teams also include the name and contact information of the direct supervisors for each member of the ART to ensure proactive communication and coordination takes place with these managers before changes are announced (they should also be invited to attend Leading SAFe!).

Train Product Owners and Product Managers

Product Managers and Product Owners steer the train together. They have content 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 well trained to ensure optimal collaboration, learn the new way of working, and understand how to best fulfill their specific responsibilities. In addition, these roles will be largely responsible for building the initial program backlog, which is a key 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 the delivery of value in the SAFe enterprise. Attendees get an overview of SAFe’s Lean-Agile Mindset and principles, as well as an in-depth exploration of role-specific practices. Attendees learn how to write Epics, Features, and User Stories, how to establish the Team and Program Kanban systems to manage the flow of work, and how to manage and prioritize backlogs using Weighted Shortest Job First (WSJF).

Train the Scrum Masters

Effective ARTs, in large part, rely on the servant leadership of the Scrum Master and their ability to coach Agile Team members and improve the performance of the team. It’s a specialty role that includes traditional Scrum leadership duties, as well as responsibilities to the larger team-of-Agile-teams that constitute the ART. In SAFe, Scrum Masters also play a critical role in PI planning and help coordinate value delivery through Scrum of Scrums events. Obviously, it’s incredibly helpful if they receive appropriate training prior to the start of the first PI.

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

Train the System Architects/Engineers

System Architects/Engineers support solution development by providing, communicating and evolving the broader technology and architectural view of the solution.  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 not only be experienced technical experts but must be effective Lean-Agile Leaders skilled at engaging across the organization.  Partnering with Product Management, this role takes on, defines and owns enabler features in the backlog designed to maintain the architectural runway necessary to sustain business value creation.

Scaled Agile, Inc.’s three-day SAFe System and Solution Architect 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 key 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 some of the ART readiness assessment and activities.

Most would agree that the majority of the items in Figure 3 are required for a successful launch. The items in Figure 4 are certainly desirable, but depending upon your circumstances, they can also be addressed easily over the first few PIs.

Prepare the Program 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 prior to 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 prior to the launch date.

The scope of the PI, or ‘what gets built,’ is largely defined by the Program Backlog, which contains the set of upcoming features, NFRs, and architectural work that define the future behavior of the system. 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.

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. They typically know what’s best anyway. 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. It’s also a sure way to demotivate the teams, as creating stories is a significant aspect of their contribution to PI planning.

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
• Trained executives, managers, and leaders
• Identified value streams and ARTs
• 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 next article in this series, Train Teams and Launch the ART.

Learn More

Additional Resources

• Leading SAFe
• SAFe POPM
• SAFe Scrum Master

Last update: 10 February 2021