Short-term wins help build necessary momentum.
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 ART launch.
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 program 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
- 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 was 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 .
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. “Taking 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 meetings
- 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 meetings, 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 stakeholders (Business Owners, managers, internal suppliers, operations, etc.) who have not attended a Leading SAFe training session. They will likely be unfamiliar with SAFe and 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
During the implementation workshop, questions will arise as to how to organize the Agile teams with respect to the system architecture and solution purpose. Similar to organizing the ARTs themselves (see Create the Implementation Plan), there are two primary patterns for organizing Agile teams:
- Features teams – Are focused on user functionality and are optimized for fast value delivery. This is the preferred approach, as each is capable of delivering end-to-end user value. They also facilitate the growth of “T-shaped”  individual skills.
- Components teams – Are optimized for system robustness, component reuse, and architectural integrity. It is recommended that their use is limited to when there are significant component reuse opportunities, high technical specialization, and critical Nonfunctional Requirements (NFRs). After a component has matured, the feature teams, with some lightweight governance, can take on the future development of the component. The original component team can then be reorganized for other feature or component work.
Most ARTs have a mix of feature and component teams (see the Guidance article). However, ARTs should generally avoid organizing teams around a technical system infrastructure (architectural layer, programming language, middleware, user interface), as this creates many dependencies, impedes the flow of new features, and leads to brittle designs.
Forming the Agile Teams
The next step is to form the Agile teams that will be on the train. One innovative solution is to enable the people on the ART to organize themselves into Agile teams with minimal constraints (see Em-Campbell Pretty’s blog on self-organization ). 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.
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. These rules of Agile (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.
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 meetings. 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.
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 workshops and other activities, as illustrated in Figure 5.
It’s easy to over-invest in backlog readiness, so don’t let that bog you down, as the act of planning with the teams will sort out many issues. They typically know what’s best anyway. It has been our experience that a list of well-written features with initial acceptance criteria is sufficient. Many tend to over-plan and create the 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.
So far, it’s been quite a journey. Here’s what we’ve 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. Are you ready? Good! Now you’ll want to read the next article in this series, Train Teams and Launch the ART.Next
Learn More Thanks to SPCT Mark Richards for the ART Canvas inspiration.  https://en.wikipedia.org/wiki/T-shaped_skill
Last update: 8 October 2017