Short-term wins help build necessary momentum.
—Kotter
By now, the enterprise has identified its 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 chapter describes the activities necessary to prepare for the 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, some larger activities are part of preparing the launch:
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 following sections.
In creating the implementation plan, stakeholders defined a process to identify the first value stream and ART. 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 ART canvas is that it helps 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 this 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—for example, vice presidents 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.
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 in turn 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 and 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
Having such advance notice of upcoming activities 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 then be scheduled, with each team defining the time and place for its 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.
Depending on the scope and timing of the rollout, there may be a number of ART stakeholders (e.g., Business Owners, managers, internal suppliers, operations) who have not attended a Leading SAFe training session. They will likely be unfamiliar with SAFe and unclear on expectations, and they may not understand the need for and benefits of their participation. It’s important that they understand and support the model, as well as the responsibilities of their role.
To ensure their commitment to the plan, 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.
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 Creating the Implementation Plan in Part 2), there are two primary patterns for organizing Agile teams:
Features teams – These teams are focused on user functionality and are optimized for fast value delivery. This is the preferred approach, as each features team is capable of delivering end-to-end user value. They also facilitate the growth of “T-shaped” [2] individual skills.
Components teams – These 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 features teams, with some lightweight governance, can take on future development of the component. The original component team can then be reorganized to assume other feature or component work.
Most ARTs have a mix of features and components teams (see Features and Components in Part 9). However, ARTs should generally avoid organizing teams around a technical system infrastructure (e.g., architectural layer, programming language, middleware, user interface), as this creates many dependencies, impedes the flow of new features, and leads to brittle designs.
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 [3]). In other cases, management makes the initial selections based on the managers’ 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. In addition, the initial roles of Scrum Master and Product Owner must 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 this kind of 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 of Figure 2 is quite interesting, as it defines the level of collocation and distribution for each team. Collocation is better, of course. In some cases, however, one or more individuals may not be able to be physically collocated with the others. That situation 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.
Product Owners and Product Managers 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. This 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 and have the opportunity to engage in 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).
Effective ARTs, in large part, rely on the servant leadership of their Scrum Masters and their ability to coach Agile Team members and improve the performance of the team. It’s a specialty role that includes both traditional Scrum leadership duties and responsibilities relevant 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 explores the role of Scrum in the context of SAFe. It prepares Scrum Masters to facilitate team iterations, to successfully plan and execute the PI, to participate in ART events, and to measure and improve the flow of work through the system using Kanban. This course is beneficial for both new and experienced Scrum Masters.
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 is 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 on your circumstances, they can be addressed easily over the first few PIs.
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 the PI planning meeting without a solid sense of the mission. While it’s tempting to assume that kind of understanding will be shared prior to the event, experience often shows otherwise. It’s more likely that team members will have 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 Lean-Agile Center of Excellence (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 preparation bog you down: The act of planning with the teams will undoubtedly sort out many of these issues. Anyway, the teams typically know what’s best. Our experience shows that a list of well-written features with initial acceptance criteria is sufficient. Many leaders 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 chapter, Train Teams and Launch the ART.
LEARN MORE
[1] Thanks to SPCT Mark Richards for the ART Canvas inspiration.
[2] https://en.wikipedia.org/wiki/T-shaped_skill
[3] http://www.prettyagile.com/2017/01/facilitating-team-self-selection-safe-art.html
