Agile Release Train
The Agile Release Train (ART) is a long-lived team of agile teams, typically consisting of 50-125 individuals, that serves as the program-level value delivery mechanism in SAFe. Using a common cadence, each train has the dedicated resources necessary to continuously define, built, test and delver value to one of the enterprises value streams. Each train produces valuable and evaluate-able, system-level increments every two weeks, and additional quantum, Program Increment milestones every 8-12 weeks. ARTs can Release at any time in accordance with market needs.
The Agile Team is the SAFe atomic software development unit, a cross-functional group of individuals with the ability and authority to define, build and test value. Teams of 7 +/- 2 members are dedicated to a single Agile Release Train, including developers, testers, any specialized resources, a Scrum Master, and a Product Owner. Teams apply Scrum project management practices, XP inspired Code Quality practices, and have an understanding of lean thinking, flow and work in process. Some teams use Scrumban or kanban, depending on their role in the train.
Architectural Epic Kanban
The Architectural Epic Kanban system brings visibility, work in process (WIP) limits and continuous flow to Portfolio Level Architectural Epics. The Architectural Epic Kanban System is typically under the auspices of the CTO/technology office, which typically includes Enterprise and System Architects.
Architecture Epics are the large technology initiatives necessary to evolve portfolio solutions in order to support current and future business needs. Architectural Epics are captured and analyzed in the Architectural Epic Kanban System. Those that are approved wait in the Portfolio Backlog until resources are available for implementation.
Architectural Features are technical systems services, infrastructure, components, and other foundational elements needed by developers to implement the business Features that deliver solution value to the end users and the enterprise.
Architectural Runway is the existing technical infrastructure, instantiated in code, necessary to support the implementation of upcoming features without excessive, delay-inducing, redesign. Each Release Train endeavors to continuously extend the Architectural Runway so as to be sufficient to support the successful implementation of features over the next one to two Program Increments.
ART Metrics include: self-assessments the can be used to assess the organizational health of each Agile Release Train and Agile Team; Iteration and Program Increment metrics designed to help teams measure their asset health of the software they are building; and progress reports which help all stakeholders understand the progress of each Feature in a Release.
Budgets provide the operating boundaries for the investment in people, expenses and other resources for an Agile Release Train. SAFe’s Lean-Agile budgeting approach eliminates the overhead and friction of project-based cost accounting, and instead allocates resources to long-lived teams of teams, each dedicated to implementing a portion of a value stream.
Business Epic Kanban
The Business Epic Kanban system brings visibility, flow and work in process (WIP) limits to Portfolio Level Business Epics. The Business Epic Kanban System is typically under the auspices of Program Portfolio Management, comprised of those executives and Business Owners who have the responsibility for implementing business strategy.
Business Epics are large customer-facing initiatives that encapsulate the new development necessary to realize the benefits of some new business opportunity. Business Epics are captured and analyzed in the Business Epic Kanban System. Those that are approved wait in the Portfolio Backlog until resources are available for implementation.
Business Owners are a small group of management stakeholders who have the primary efficacy, governance, and ROI responsibility for the value delivered by a specific release train. Business Owners play a key role throughout the flow of value, and have particularly critical roles during Release Planning, where they participate in the management review and problem solving meeting, approve plans, and assign Business Value to Team PI Objectives.
Code Quality is a mindset, culture, and set of technical of practices which help teams deliver: higher system quality; high velocity and agility; opportunity for enhanced innovation; and helps support the intrinsic motivation and pride of software development professionals. Code Quality is one of the four Core Values of SAFe and is achieved in large part through adoption of Test-First Methods, Agile Architecture, Continuous Integration, and Refactoring, all of which are described in SAFe, plus pair work and collective ownership.
When a value stream is too big for a single ART, then multiple ARTs are necessary to deliver that value, and they typically have functional, technical, and even personnel dependencies that need to be routinely managed. In this case, delivery of end user value becomes dependent on Coordination of content management, integration, and releasing.
Developers & Testers
Developers and testers make up the majority of an Agile Team. Developers write the code for the User Stories and conduct research, design, and prototyping with Spike stories. The developer’s responsibilities include collaborating with the Product Owner and testers to make sure the right code is being developed; pairing, writing the code, unit tests, and automated acceptance tests; and checking new code into the shared repository every day. Testers work collaboratively and in parallel with developers and Product Owners to define, write and execute acceptance tests, and maintain the test cases in a shared repository.
DevOps is a philosophy of approach to software development and a set of practices that stresses communication, collaboration and close cooperation between the agile development teams and information technology professionals who are responsible for deploying and maintaining the software systems. This is accomplished, in part, by including IT/deployment/operations personnel as members of the Agile Release Train and by following a set of DevOps guidance practices.
The Enterprise Architect works with business stakeholders and System Architects to drive holistic technology implementation across programs. The enterprise architect relies on continuous customer and team feedback, fosters adaptive design and engineering practices and drives collaboration of programs and teams around a common technical vision.
The Epic Owner is responsible for driving individual Epics from identification, through the kanban systems and analysis process, to the go/no-go decision making process, and when accepted for implementation, working with the Release Train to initiate the development activities necessary to realize the benefits of the epic.
Epics are enterprise initiatives that are sufficiently substantial in scope so as to warrant analysis and understanding of potential ROI before implementation. Epics are typically cross-cutting and effect multiple organizations, release trains and multiple Program Increments. Epics require a lightweight business case that elaborates business and technology impact and implementation strategies. Portfolio Epics affect multiple release trains; Program Epics are contained to a single train.
Features are services provided by the system that fulfill one or more stakeholder needs. They are maintained in the Program Backlog and are sized to fit in a Program Increment so that each PI provides a quantum of conceptual integrity. Features bridge the gap between User Stories (sized to fit in iterations) and Epics (which span PIs). Because the primary economic program benefit is driven by judicious prioritization and sequencing of features, SAFe applies the lean economic algorithm of Weighted Smallest Job First (WSJF) for continuous prioritization.
Innovation and Planning
SAFe provides for periodic Innovation and Planning sprints, which serve a variety of purposes, including: providing an estimating buffer for meeting objectives; a dedicated time for Inspect and Adapt and Release Planning activities; a cadence-based opportunity for innovation; time for continuing education; time for working on the technical infrastructure, tooling, and any other impediments; and time for backlog refinement. In addition, in the case where the PI milestone also constitutes a Release, the IP iteration provides time for any final system validation and documentation activities that may be required.
Inspect & Adapt
Inspect and Adapt (I&A) is a regular ceremony, held at the end of each PI, that provides teams and groups time to reflect, problem solve, and identify improvements actions. Teams demonstrate the current state of solution to the appropriate stakeholders, thereby getting the fast feedback they need to need to steer a proper course. Performance measures are collected and analyzed. This is followed by a retrospective and problem solving workshop, which generates improvement stories and other process learnings, which can then be immediately incorporated during Release Planning.
The Iteration (synonymous with sprint) is a strict time-box in which teams deliver incremental value in the form of working, tested software. Each iteration has a standard pattern: plan the iteration; commit to a goal; execute; demo the work to the key stakeholders; and, finally, hold a Retrospective, wherein the team analyzes and determines changes necessary to improve its performance.
Iteration Planning is the ceremony during which the all team member plan the upcoming iteration. The output of the meeting includes: the sprint backlog, consisting of the stories and acceptance criteria committed to the sprint; a statement of sprint goals, which are the business objectives of the sprint; and finally, a commitment by the team to the work needed to achieve the goal.
The Iteration Retrospective is a short meeting held at the the end of each Iteration, wherein team members gather in a private, safe environment to discuss the efficacy of their practices and define improvements for the upcoming period. The quantitative portion reviews any metrics the team is using; the qualitative part discusses the various team practices, and the specific challenges that presented themselves. When issues have been identified, teams identify corrective actions needed to address those issues.
Lean thinking is a set of principles and practices that maximize customer value while minimizing waste and reducing time to market. The goal of Lean is sustainably shortest lead time, with best value to people and society. Lean thinking incorporates five major elements: the goal, kaizen (continuous improvement), product development flow, respect for people and Lean-Agile Leadership. Lean Thinking is essential to scaling agile practices to the enterprise level, and is therefore foundational to SAFe.
Lean-Agile Leaders are life-long learners, managers, teachers, and coaches who help teams build better software systems through understanding and exhibiting the values, principles and practices of Lean, systems thinking and Agile software development. Lean-Agile Leaders adhere to Four Principles of Lean-Agile Leadership.
Nonfunctional Requirements (NFR), describe system attributes such as security, reliability, maintainability, scalability, and usability (often referred to as the “qualities” or “ilities”). They can also be constraints or restrictions on the design of the system. Nonfunctional Requirements are persistent qualities and constraints, and unlike functional requirements, are typically revisited as part of the “Definition of Done”. NFRs exist at Team, Program and Portfolio Backlog levels.
The Portfolio Backlog is the highest-level backlog in SAFe, and serves as a holding stage for Epics that make it through the Kanban systems and await implementation. It contains the prioritized set of Business and Architectural Epics necessary to achieve market differentiation, operational efficiencies, or competitive solutions.
Portfolio metrics include a self-assessment that can be used to better understand the state and progress of the Program Portfolio Management function itself; metrics which track portfolio epics as they move though the kanban system and into implementation; and a summary set of Lean metrics that can be used to assess the overall health of the entire program portfolio.
The Portfolio Vision captures strategic intent and provides guidance for purposeful investments of time, money and resources to achieve program portfolio objectives. Comprised of Value Streams, Strategic Themes, Business and Architectural Epic Kanbans and the Portfolio Backlog, the Portfolio Vision reflects an elaboration and commitment to action to the enterprise’s business strategy.
Product Management serves as the content authority for the Agile Release Train and is responsible for defining and prioritizing the Program Backlog, as well as prioritizing Features to be included in a Program Increment and Release. They work with internal and external stakeholders, including Product Owners, to optimize feature delivery in balance with the enterprises technical, functional, and economic objectives.
The Product Owner is the member of the Agile team responsible for defining and prioritizing the Team Backlog. The Product Owner also serves as part of the extended Product Management-Product Owner team, who together, have the authority for what gets developed. In addition, the Product Owner has a significant role in assuring user value and solution quality, and is the only team member empowered to accept new stories into the system baseline.
The Program Backlog is the single, definitive repository for all the upcoming work anticipated to satisfy the Agile Release Train objectives. It primarily includes future Features intended to address user needs and deliver business benefits, and also includes the Architectural Features required to build the Architectural Runway necessary to host the upcoming feature backlog.
Program Epics are epics that are constrained to a single train. Because of their scope, impact and cost, they may be introduced through the kanban systems and portfolio backlog, or they may arise locally, but they require analysis and impact assessment—and some discussion with Program Portfolio Management—before implementation.
Program Portfolio Management
Program Portfolio Management (PPM) represents the highest-level fiduciary and content authority in a program portfolio. These responsibilities rest with the business executives who have the necessary knowledge and best understand the internal financial constraints and external market conditions for each Value Stream.
Program PI Objectives
Program PI Objectives are a summarized description of the specific goals and business values intended for the upcoming PI(s). Program PI Objectives are derived by synthesizing the Team PI Objectives that are established by the teams during Release Planning.
Refactoring is a systematic approach to improving the code base without changing external system behavior. Specific refactors appear as Team Backlog items that are necessary to accomplish such things as increases in processing speed, different sourcing of internal data, security enhancements, or streamlining some aspect of the code to make it more efficient, more maintainable, or more readable.
Releases embody the whole product solution, whereby the end user gets the full benefit of the developed working software, validated, packaged, documented and supported by all the elements necessary to assure efficacy of the solution in the customers environment.
Release Management is the authority responsible for governing releases across one or more release trains. Their primary responsibility is to coordinate and facilitate the delivery of General Availability software, or internal, production-ready solutions.
Release Planning is the seminal, cadence-based synchronization point of the Agile Release Train. Release planning is a routine, program-scale, face-to-face event with a standardized agenda that includes presentation of vision, team planning breakouts, and commitment to objectives for the next Program Increment.
Release Train Engineer (RTE)
The Release Train Engineer is the “Chief Scrum Master” who facilitates program-level processes and program execution, escalates impediments, manages risk, and helps drive program-level continuous improvement. RTEs are responsible for facilitating program events such as Release Planning, the Inspect & Adapt Workshops, and the Scrum of Scrums.
The Roadmap provides a view of the intended deliverables, such as Features, Epics, Releases and other milestones, over a timeline horizon of approximately three to six months. The Roadmap typically includes high confidence Feature visibility into the upcoming Program Increment, medium confidence visibility into the next, and relatively lower confidence thereafter.
The Scrum Master is a team member with the primary responsibility to help the self-organizing, self-managing team meet its goals and commitments, and continuously improve performance. They understand and teach Scrum, Agile and Lean practices, encourage XP inspired technical practices, and foster the collaboration necessary to help identify and eliminate impediments, and constantly improve its performance.
The Program Level describes most of the roles and teams that are dedicated to the specific value stream that is the subject of that Release Train. However, Programs also require access to specialty, shared resources, such as security specialists, information architects, DBAs, documentation, IT and more. Depending on the organization and the scope of the Release Train, these resources may be dedicated to the program for a time period, but are more likely matrixed from other functional departments.
Spikes are a type of story used for activities such as research, design, exploration and prototyping. The purpose of a Spike is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a Story estimate. Spikes primarily come in two forms, technical and functional. Like other stories, Spikes are estimated, owned by a team member, and are demonstrated at the end of the iteration.
Sprint goals are a high level summary of the business and technical goals that the team and product owner agree to accomplish in a sprint. In SAFe, Sprint goals are integral to the effective coordination of an Agile Release Train as a self-organizing, self-managing team of teams. Sprint goals provide value by 1) aligning the individual team members and product owner to a common mission for the sprint; 2) continually aligning the individual teams to the PI objectives, 3) providing a simple communication protocol between the teams, management, and business owners.
Stories are the Agile replacement for traditional forms of requirement specifications. Stories are small, independent behaviors that can be implemented incrementally, each of which provides value to the business. Stories are not requirements, in that they are generally negotiable and represent a statement of intent rather than a contractually required behavior. However, through acceptance criteria, stories get more specific as they are implemented, providing the necessary specificity for assuring system compliance and regression testing. Stories are split as necessary so they can be completed in a single iteration.
Strategic Themes are specific, itemized business objectives, new business differentiators that connect the portfolio vision to the evolving enterprise business strategy. They provide business context for decision-making within the portfolio, affecting investment in value streams and release trains, and serve as inputs to the Portfolio and Program Backlogs.
The System Architect has the responsibility for maintaining a high level understanding of the user’s needs, system requirements and business benefits for a Release Train. System Architects provide guidance on Agile, intentional architecture, system level refactoring and redesign, Nonfunctional Requirements, foster emergent design and architectural flow, assist with understanding interfaces and dependencies, and facilitate interdependent team design decisions.
The System Demo occurs every two weeks and provides an aggregate – and integrated – view of a system increment, all the new software that has been delivered by all the teams in the program to that point. Often hosted by the System Team, the System Demo is used to get feedback from the primary stakeholders, including Product Management, management, customers (or customer proxies), on the efficacy and usability of the system under development.
A System Team is often responsible for providing assistance in building and utilizing the development environment infrastructure and evaluating the system increments. This can include development and maintenance of continuous integration, build environments, testing platforms and testing automation frameworks, and integrating code from Agile Teams. The System Team also has the skills and tools needed to perform end-to-end system testing, demonstrate solutions to stakeholders and assist with Nonfunctional Requirements system testing.
The Team Backlog represents the collection of all the things a team needs to do to advance their portion of the program solution. It can contain user and technical Stories, future Features, technical stories, defects, infrastructure work, Spikes, Refactors, and anything else a team needs to do. Specific capacity allocations by Story type are often used to guide investment in the various types of work the team needs to do.
The Team Demo is the traditional, Scrum-prescribed ceremony where the team demonstrates the results of the work done in the iteration. The purpose of the Team Demo is to measure the team’s progress by showing working software to the Product Owner, other team members, and other relevant stakeholders. The preparation for the Demo begins when the sprint is planned—teams start thinking about how they will demonstrate the stories during Sprint Planning. Teams should be able to demonstrate every Story, Spike, Refactor, and new NFR.
Team PI Objectives are a summarized description of the specific business and technical goals that a team intends to achieve in the upcoming PI. During release planning, each team reviews the vision and any other input objectives, defines initial user stories, and plans them into iterations until their capacity is reached. They then use those results to reflect on the plan and synthesize and summarize the specific technical and business objectives for their team for that PI. The aggregation of each team’s objectives becomes the Program PI Objectives.
User Experience (UX)
While Agile Teams have the full responsibility for implementing the code, including the user interface (UI) elements, the User Experience designer works at the Program Level to provide cross-component and cross-program design guidance so as to provide a consistent user experience across the components and systems of the solution.
A software value stream is the series of system definition, development and deployment process steps used to provide a continuous flow of value to the business, customer or end user. Each should be a compelling, longer-term initiative that drives programs that ultimately differentiate an enterprise from its competitors. Agile Release trains are formed inside Value Streams to simplify development, eliminate unnecessary steps and handoffs, and to accelerate the delivery of value via implementation of Lean and Agile principles and practices.
The Vision describes the stakeholders view of the solution to be developed, in terms of stakeholders needs and proposed features. It captures the essence of the envisaged solution in the form of high-level Features, Nonfunctional requirements and design constraints, and provides an overview of the system to be developed. It describes the purpose for the program and provides the boundaries against which future Features, Stories and decisions are based. Continuously communicating the Vision to all team members is critical to creating alignment and a shared understanding of goals and objectives.
Weighted Shortest Job First (WSJF)
WSJF is a lean method for determining backlog prioritization and job sequencing using the cost of delay and remaining job size. This algorithm is applied at PI boundaries to continuously update program priorities based on current business context, time, value, development facts, risk, and effort considerations.
Last update: 25 July, 2014
© 2010-2014 Leffingwell, LLC. All rights reserved.