One of the most important changes in how work gets done in an agile organization is the shift from doing work based on temporary project teams to organizing around business value streams. A value stream is the set of business workflow steps performed by a business unit in order to deliver value – a product or service – to a customer. A product (or service – a “service product”) can be thought of as a vehicle to deliver value. Project-to-Product is another popular characterization of this concept. A large business enterprise may have multiple value streams .
Value streams (products) differ from traditional project models in a number of ways:
- Based on dedicated teams, with longevity and stability, focused on a long-term business mission, instead of temporary groups organized around short-term projects.
- Long-lived teams can better align their work with a business mission and KPIs and work over longer timeframes to make a measurable impact.
- Long-lived teams are better positioned to develop greater improvements to their delivery effectiveness through the process of continuous improvement.
An Agile Release Train (ART) is a collection of agile teams organized to support an individual value stream. The teams in an ART collaborate on a common vision, strategy and program backlog, and operate via common governance mechanisms for planning and synchronization of their work. In SAFe, ARTs are the vehicle for executing product strategy and delivering value through working software .
Setting up an ART involves a number of essential steps.
- ART Design. Agile Release Train design usually begins by defining the vision, mission, strategy and success factors (KPIs) for the ART. The actual workflow steps that the ART uses to deliver value to its customers can be elaborated using a value stream mapping exercise. The systems and associated teams that support each part of the business workflow are also identified during this exercise. Once the basic work processes of the ART are defined, key roles needed to support operation of the framework must be identified and trained appropriately. These roles include Release Train Engineer (RTE), Product Manager, and System Architect.
- Release Train Engineer (RTE): Acts as ‘Chief Scrum Master’ for the ART. Facilitates all ART events (PI Planning, Scrum-Of-Scrums, ART Sync), takes the lead on ART impediment removal, and is responsible for ensuring the ART is continuously improving its performance.
- Product Manager: Acts as ‘Chief Product Owner’. Responsible for ‘what gets built’. Works with customers and business owners to understand their needs and provide clarity for the delivery teams. Owns and manages the Program Backlog.
- System Architect: Defines the overall architecture of the system. Identifies architectural runway needs, non-functional requirements, and system interfaces.
- Business Owners: Key stakeholders, who are responsible to the organization for the ultimate business outcomes delivered by the ART.
- Team Design. Upon completion of the value stream mapping exercise we should have a good idea of the systems needed to support each part of the business workflow. These systems need ongoing development and support, and one approach to ART design is to align individual delivery teams with these systems. In this way teams can be focused directly on business value. By connecting work to strategy and business outcomes using KPI Driver Trees, that value can actually be measured using KPIs.
A central principle in agile team design is that they are small (less than 10 members), self-organized (have total control over how to build things) and cross-functional (have all the skills necessary to deliver working software in small increments that represent value to actual users). Care should be taken to minimize the dependencies between teams. Dealing with dependencies makes planning and execution much more complicated, exerting a drag on team velocities. However, it is usually not possible to completely eliminate all dependencies.
Team rosters comprising one full-time Product Owner, one full-time Scrum Master and a fully dedicated development team need to be in place for each team on the ART. Without these in place, teams will never develop a stable velocity, and without a stable velocity they will not be able to plan or make commitments.
- Team Training. Teams need to be able to plan and execute sprints. This knowledge is acquired through training. Experience actually sprinting is also essential so that teams can acquire a stable velocity which can then be used as the basis of planning and making commitments. It may take teams several sprints to get to a reasonably stable velocity. We will see later that ARTs built upon a collection of trained teams with stable velocity is an important preliminary step for PI Planning.
- Team Readiness. Sometimes referred to as ‘Sprint-0’, many newly formed teams take time out in advance of their first real sprint to orient themselves to a mission and near-term objectives. Once that is done they can begin creating and refining an initial backlog of user stories, and should be able to articulate how this work connects with their mission. (This could include a review of their value driver tree, and confirmation of how their proposed work connects to it, and in turn, the strategy and target outcomes for their business). Finally, before they begin sprinting, teams need to align on a Definition Of Done, Definition Of Ready, Team sprint calendar, and team working agreement.
- ART Readiness. ART mobilization will include getting tooling infrastructure in place and agreeing on some basic usage standards, defining the key ART events and associated cadences, aligning on the artifacts that will be used to support events like Scrum Of Scrums and ART Sync meetings. Scheduling the first PI Planning event and creating a Program Backlog for the first PI.
- ART Kickoff Event. Once the preceding is done, or mostly done, hold a kickoff event to communicate the mobilization of the ART. This should be a town hall type of event (either live or virtual), with all of the teams, ART leadership, business stakeholders and other partners. The event is led by the ART Product Manager or other senior leader, and facilitated by the RTE. Topics covered should include the ART vision, strategy, success factors and any near-term business objectives. Present the team structure (list of teams and associated missions if any) and any newly appointed Product Owners or Scrum Masters, along with the Names of the people in the key ART roles. Announce the upcoming first PI Planning event and work needed to prepare for it, including any training that will be offered on the actual planning process.
More here:
