Agile Release Train Flashcards
Agile Release Train
The Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops, delivers, and where applicable operates, one or more solutions in a value stream.
ART Details
Agile Release Trains align teams to a shared business and technology mission.
Each is a virtual organization (typically 50 – 125 people) that plans, commits, develops, and deploys together.
ARTs are organized around the Enterprise’s significant Development Value Streams and exist solely to realize the promise of that value by building Solutions that deliver benefit to the end-user.
ARTs are cross-functional and have all the capabilities—software, hardware, firmware, and other—needed to define, implement, test, deploy, release, and where applicable, operate solutions.
An ART delivers a continuous flow of value, as shown in Figure 1.
ARTs operate on a set of common principles:
The schedule is fixed – The train departs the station on a known, reliable schedule, as determined by the chosen Program Increment (PI) cadence.
If a Feature misses a timed departure and does not get planned into the current PI, it can catch the next one.
A new system increment every two weeks – Each train delivers a new system increment every two weeks.
The System Demo provides a mechanism for evaluating the working system, which is an integrated increment from all the teams. Synchronization is applied –
All teams on the train are synchronized to the same PI length (typically 8 – 12 weeks) and have common Iteration start/end dates and duration.
The train has a known velocity – Each ART can reliably estimate how much cargo (new features) can be delivered in a PI.
Agile Teams – Agile Teams embrace the ‘Agile Manifesto’ and SAFe Core Values and Principles.
They apply Scrum, Extreme Programming (XP), Kanban, and other Built-In Quality practices.
Dedicated people – Most people needed by the ART are dedicated full time to the train, regardless of their functional reporting structure.
Face-to-face PI Planning – The ART plans its work at periodic, mostly face-to-face PI Planning events.
Innovation and Planning (IP) – IP Iterations occur at the end of every PI and provide an estimating guard band (buffer) as well as dedicated time for PI planning, innovation, continuing education, and infrastructure work.
Inspect and Adapt (I&A) – An I&A event is held at the end of every PI. The current state of the solution is demonstrated and evaluated.
Teams and management then identify improvement backlog items via a structured, problem-solving workshop.
Develop on Cadence, Release on Demand – ARTs apply cadence and synchronization to help manage the inherent variability of research and development. However, releasing is typically decoupled from the development cadence.
ARTs can release a solution, or elements of a solution, at any time, subject to governance and release criteria.
ARTs are Organized Around Value
Instead, the ART applies systems thinking (SAFe Principle #2) and organize around value (SAFe Principle #10) to build a cross-functional organization that is optimized to facilitate the flow of value from ideation through deployment and release, and into operations, as
Together, this fully cross-functional organization—whether physical (direct organizational reporting) or virtual (line of reporting is unchanged)—has everyone and everything it needs to define, deliver, and operate solutions.
It is self-organizing and self-managing. This creates a far leaner organization; one where traditional daily task and project management is no longer required. Value flows more quickly, with a minimum of overhead.
SAFe applies four fundamental team topologies
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.
Critical ART Roles
In addition to the Agile teams, the following roles help ensure successful execution of the ART:
Release Train Engineer (RTE) is a servant leader who facilitates program execution, impediment removal, risk and dependency management, and continuous improvement.
Product Management is responsible for ‘what gets built,’ as defined by the Vision, Roadmap, and new features in the Program Backlog. They work with customers and Product Owners to understand and communicate their needs, and also participate in solution validation.
System Architect/Engineering is an individual or team that defines the overall architecture of the system. They work at a level of abstraction above the teams and components and define Nonfunctional Requirements (NFRs), major system elements, subsystems, and interfaces.
Business Owners are key stakeholders of the ART and have ultimate responsibility for the business outcomes of the train.
Customers are the ultimate buyers of the solution. In addition to these critical ART roles, the following functions play an essential part in ART success:
System Teams typically assist in building and maintaining development, continuous integration, and test environments.
Shared Services are specialists—for example, data security, information architects, database administrators (DBAs)—that are necessary for the success of an ART but cannot be dedicated to a specific train.
Cadence and Synchronization
ARTs also address one of the most common problems with traditional Agile development: Teams working on the same solution operate independently and asynchronously. That makes it extremely difficult to integrate the full system routinely. In other words, ‘The teams are iterating, but the system isn’t.’ This increases the risk of late discovery of issues and problems
Cadence and synchronization assure that the focus is continuously on the evolution and objective assessment of the full system, rather than its elements. The system demo, which occurs at the end of every iteration, provides the objective evidence that the system is iterating.
ART Execution, DevOps, and Continuous Delivery
Each ART builds and maintains (or shares) a Continuous Delivery Pipeline with the assets and technologies needed to deliver solution value as independently as possible.
The first three elements of the pipeline work together to support the deployment of small batches of new functionality, which are released to meet market demands.
Continuous Exploration is the ongoing process of exploring the market and user needs, and defining a Vision, Roadmap, and set of hypotheses to address those needs.
Continuous Integration is the process of taking features from the program backlog and developing, testing, integrating, and validating them in a staging environment where they are ready for deployment and release.
Continuous Deployment is the process that takes validated features and deploys them into the production environment, where they’re tested and ready for release.
Release on Demand is the process of making the value available to the end-user, measuring and learning from the results of the hypotheses, and operating the solutions.
Development and management of the Continuous Delivery Pipeline are supported by DevOps, a capability of every ART.
Flow through the system is visualized, managed, and measured by the Program Kanban.
ARTs Deliver All or Part of a Value Stream
The organization of an ART determines who will plan and work together, as well as what products, services, features, or components the train will deliver.
Organizing ARTs is part of the ‘art’ of SAFe.
This process is covered extensively in the Implementation Roadmap article series, particularly in ‘Identify Value Streams and ARTs‘ and ‘Create the Implementation Plan.’ Effective ARTs typically consist of 50 – 125 people.
The upper limit is based on Dunbar’s number, which suggests a limit on the number of people with whom one can form effective, stable social relationships.
The lower limit is based mostly on empirical observation. However, trains with fewer than 50 people can still provide good value, and provide many advantages over legacy Agile practices for coordinating Agile teams.
Given the size constraints, there are two main patterns of ART design (Figure 10): Smaller value streams can be implemented by a single ART A larger value stream must be supported by multiple ARTs
