“Short-term wins help build necessary momentum.”
This article is part of the SAFe® Implementation Roadmap series which outlines and discusses the primary ‘critical moves’ that are common to successful SAFe transformations. To view the Roadmap and find links to the entire set of supporting articles, click here.
Prepare for ART Launch
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
- Charter a Lean-Agile Center of Excellence (LACE)
- Identify Value Streams and 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 Agile Release Train (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. As we described in Train Lean-Agile Change Agents and the companion SPC article, SAFe Program Consultants (SPCs) often lead the implementation of the initial Agile Release Trains, 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 calendar
- Train the ART leaders and stakeholders
- Establish the Agile teams
- Train Product Managers and Product Owners
- Train the 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, we described the process stakeholders use to identify the first value stream and ART. At that stage of planning, the ART is defined in broad brush strokes, with just enough detail to determine that it is a prospective ART, but also enough ambiguity to leave key decisions to those who better understand the local context. The next activity is to further define the parameters and boundaries of the ART. Figure 1 below provides an “ART Canvas” that stakeholders can use for this purpose.
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. In a microcosm, 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 ten-week PI, which consists of four regular iterations and one Innovation & Planning (IP) iteration. There is no fixed rule for the PI cadence, nor for how much time should be reserved for the IP iteration. It’s recommended that a PI last between eight to twelve 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 & Adapt (I&A) workshop
This advance notice reduces travel and facility costs, and helps assure that most of the stakeholders will be able 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, demo 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, 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. Feature teams are focused on user-centered functionality. 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. Feature teams are optimized for fast value delivery.
- Components. Component teams should be used only when there are significant reuse opportunities, high technical specialization, and critical Nonfunctional Requirements (NFRs). Component teams are optimized for system robustness, component reuse, and architectural integrity. After a component has matured, the feature teams, with some lightweight governance, can take on future development of the component. The original component team can then be re-organized 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 way is to facilitate a process where the teams organize themselves (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 will be needed. Teams have well-developed 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 configuration 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 colocation and distribution for each team. Colocation 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 Managers and Product Owners
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’s two-day SAFe Product Manager/Product Owner 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’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 Program Increment (PI), how to participate in ART events, and how to measure and improve the flow of work through the system using Kanban. SAFe Scrum Masters will also learn how to be a servant leader and build high-performing Agile teams who are capable of delivering the maximum business value that is achievable through SAFe. 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 upfront will delay learning, postponing the transformation and realizing its benefits. As Confucius said, “Better a diamond with a flaw than a pebble without.”
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 of the ambiguities. 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 vison changes. It’s also a sure way to de-motivate the teams, as creating stories is a sigificant 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.
Learn More Thanks to SPCT Mark Richards for the ART Canvas inspiration.
Last update: 1 March, 2017