Agile Release Train (ART)
The Agile Release Train 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 and normalized team velocities, each train has the dedicated resources necessary to continuously define, built, test and delver value to one of the enterprises value streams. Teams are aligned to a common mission via a single Program Backlog, and include the Product Management, Architectural and UX guidance and Release Train engineer roles. Each train produces valuable and evaluate-able system-level Potentially Shippable Increments (PSI) at least every 8-12 weeks in accordance with PSI Objectives established by the teams during each Release Planning event, but teams can release at any time in accordance with market needs.
The Agile Team is the atomic software development unit, comprised of a cross functional group of individuals with the ability and authority to define, build and test value in a two week time box. Agile Teams typically have 7 +/- 2 members, including developers, testers, a Scrum/Agile Master, and Product Owner. Agile Teams are dedicated to a single Agile Release 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 Kanban system typically includes four states: funnel, backlog, analysis and implementation. The Architectural Epic Kanban System is typically under the auspices of the CTO/technology office, which 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 in the Architectural Epic Kanban System where they move from funnel to backlog to analysis and 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 extant technical infrastructure (instantiated in code) necessary to support the implementation of upcoming features without excessive, delay-inducing, redesign. Each Release Train commits to the continuous development of Architectural Runway sufficient to support the implementation of features over the next one to two PSIs.
Business Epic Kanban
The Business Epic Kanban system brings visibility, flow and work in process (WIP) limits to Portfolio Level Business Epics. The Kanban system typically includes four states: funnel, backlog, analysis and implementation. 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 in the Business Epic Kanban System where they move from funnel to backlog to analysis and 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 through the release train, 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 PSI Objectives. Business Owners often also have Portfolio Management responsibilities, and are typically involved with cross-cutting epics from the Portfolio Backlog.
Code Quality is a set of practices, a mindset and culture which delivers higher system quality, high velocity and agility of teams, increases innovation and better harnesses the intrinsic motivation of software development professionals. Code Quality is one of the four Core Values of SAFe and is achieved in large part through adoption of Agile Architecture, Continuous Integration, Test-First Methods, Refactoring, Pair Work and Collective Ownership.
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. They work collaboratively and may pair with another developer or tester. The developer’s responsibilities include collaborating with the Product Owner and testers to make sure the right code is being developed; writing the code, unit tests, and automated acceptance tests; and checking new code into the shared repository every day. Testers work in parallel with developers and Product Owners to define and write acceptance test cases (automated wherever possible) while the code is being written, interface with the Product Owner and developers to confirm that the code and acceptance tests reflect the desired functionality, execute acceptance tests, and maintain the test cases in a shared repository.
DevOps is a set of software development and deployment practices that stresses communication, collaboration and close cooperation between the agile development teams and information technology (IT) professionals who are responsible for deploying and maintain the software systems. This is accomplished, in part, by including IT professional as integral members of each Agile Release Train.
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 analysis process and Kanban systems, to the go/no go decision making process, and when accepted for implementation, working with the Release Train development teams and Product Management to initiate the development activities necessary to realize the business benefits of the epic. Once successfully initiated, the Epic Owner may have some ongoing responsibilities for stewardship and follow-on. Or, as the Features that define the Epics are eventually incorporated into Program Backlogs for routine incorporation into the solution, the Epic Owner can return to other duties or take responsibility for additional emerging Epics.
Epics are enterprise initiatives that are sufficiently substantial in scope so as to warrant analysis and understanding of potential ROI. Epics typically require a lightweight business case that elaborates business and technology impact and implementation strategies. Epics are typically cross-cutting and effect multiple organizations, budgets, release trains and occur over multiple PSIs. 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 PSIs; in that way each PSI delivers conceptual integrity to the customer. In SAFe, Features bridge the gap between User Stories (which are sized to fit in iterations) and Epics (which span PSIs). Features are estimated, sized, and split as necessary to fit within a PSI. And because the primary economic benefit is driven by the appropriate and judicious selection of features, we apply the lean economic algorithm of Weighted Smallest Job First (WSJF) to prioritizing features.
Features and Components
Features are those behaviors of the system that directly fulfill some user need. Components are distinguishable system parts that provide and encapsulate common functions needed to implement features. While Agile’s value delivery focus emphasizes features that solve user needs and differentiate solutions, resilient large-scale systems are built out of components that provide for separation of concerns, foster logic re-use, improve testability and provide a foundation for fast system evolution. Therefore, while we emphasize Feature development in Agile, we must foster balanced investments in each, as both are required for successful solutions.
Hardening | Innovation | Planning (HIP)
HIP sprints are optional, but are typically used to provide a reserve capacity that allows teams and programs to effectively address technical debt and respond to change and unforeseen events, while staying on a fixed cadence. It also allows teams to perform legitimate release-related activities – finalization of documentation, user acceptance testing, final system performance and NFR testing, and release communications – that may be impractical at every sprint. The HIP period is also used to host the Inspect and Adapt workshop and Release Planning events, building the foundation for the next PSI with technical and functional Spikes and implementing new infrastructure. It is also used to provide dedicated time for innovation and unbounded thinking via hackathons, innovation spikes, and related activities. Note: Teams should never use the HIP iteration as an excuse to defer technical debt such as final system integration, elimination of defects, deferred regression testing, and other activities that should have been performed in earlier iterations.
Inspect & Adapt
The Inspect and Adapt (I&A) workshop is a regular ceremony, held at the end of each PSI, 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. PSI 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. In other words, I&A is to the Program what the Retrospective is to the sprint.
Investment Themes reflect how a portfolio allocates budget to the various initiatives it has defined to implement the portfolio business strategy. Investment themes are portfolio-level capacity allocations in that each theme gets resource implied by the budget. This assures the enterprise behavior is true to its strategy and that it is not short-changing big or small initiatives to the point of compromising its ability to execute the agreed-to strategy required to achieve longer-term financial goals. All but one investment themes is implemented by an Agile Release Train. The portfolio backlog investment theme is different; that one reflects the capacity allocation reserved for those cross-cutting Business and Architectural Epics that help create the more holistic, comprehensive solution.
The Iteration (synonymous with sprint) is a strict time-box (two weeks in SAFe) 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 (implement the Stories in iteration backlog); demo the work to the key stakeholders; and, finally, hold a Retrospective, whereby the team analyzes and makes the changes necessary to improve its performance.
Iteration Planning is the activity during which the team plans 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 meeting is attended by the Scrum Master, Product Owner, developers and testers and any others who will be involved in the iteration.
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. Each retrospective endeavors to uncover what’s working well, what isn’t and what the team can do better next time. Each Retrospective has both quantitative and qualitative aspects. The quantitative review gathers and reviews any metrics the team is using to measure its performance. The qualitative part discusses the various team practices, and the specific challenges that presented themselves in the course of the last iteration or two.When issues have been identified, teams perform root cause analysis and identify the corrective actions needed to resolve 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-thinking leader/manager/teachers. Lean Thinking is essential to scaling agile practices to the enterprise level, and is therefore foundational to SAFe.
The primary metric for agile is whether or not working software actually exists, and is demonstrably suitable for its intended purpose. This is determined empirically, by demonstration, at the end of every single iteration and PSI. In addition, Agile processes, practices, and work products are inherently measurable. SAFe illustrates eight measurement sets that can be used to assess Team, Program, Portfolio and enterprise progress.
Nonfunctional Requirements (NFRs, or system qualities) 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. These requirements are just as critical as the functional features and user stories, as they assure the usability and efficacy of the entire system. Nonfunctional Requirements are persistent qualities and constraints, and, unlike functional requirements, are typically revisited as part of the “Definition of Done” for each iteration or Release (PSI). In SAFe , NFRs exist at both the Team and the Program Level.
The Portfolio Backlog is the highest-level backlog in the framework, 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.
The highest level of the Big Picture is the Portfolio Level, where multiple programs are aligned to the enterprise business strategy, Value Streams and Investment Themes. The Portfolio Level is where strategies that drive the enterprise initiatives are determined, and where Agile Release Train funding and Epic level decision making occurs.
The Portfolio Vision captures the purposeful investments of time, money and resources to achieve individual portfolio objectives. Comprised of Value Streams, Investment Themes, Business and Architectural Epic Kanbans and the Portfolio Backlog, the Portfolio Vision reflects an elaboration and commitment to action to the enterprise’s portfolio business strategy.
The Product Manager serves as the content authority for the Agile Release Train and is responsible for defining and prioritizing the Program Backlog, as well as deciding what Features will be included in a PSI/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. While the backlog consists primarily of future Features intended to address user needs and deliver business benefits, it also includes new Architectural Features required to build the Architectural Runway necessary to host the upcoming feature backlog. It contains all work items in consideration for the delivery of the current and possibly future releases.
The Program Level contains the broader set of roles and responsibilities that align the Team Level efforts and drive the higher end user value through PSIs and releases. The Program Level defines and manages the Release Trains through the Program Backlog, Product Managers, System Team, System Architects and UX people, and a common Vision and Roadmap. These efforts ensure that PSI/Release goals are in balance with the enterprises technical, functional, and economic objectives.
Program Portfolio Management
Program Portfolio Management (PPM) represents the highest-level fiduciary and content authority in the framework, those who have purview over the set of Release Trains within the PPM domain of concern. These responsibilities typically rest with those business executives who have the necessary knowledge and best understand the internal financial constraints and external market conditions. They use that knowledge to drive product and solution strategy and thereby have primary responsibility for development and decision making in the Investment Themes and Portfolio Kanban systems.
Program PSI Objectives
Program PSI Objectives are a summarized description of the specific goals and business values intended for the upcoming PSI(s). Program PSI Objectives are derived by synthesizing the Team PSI Objectives that are established during Release Planning. The aggregation of each team’s objectives becomes the program’s objectives, which are then summarized and published. In this way, all stakeholders know what to expect at the release boundaries, all work in process (WIP) is visible, and the program always has a current, aligned, definitive, and communicated set of business objectives.
The PSI (Potentially Shippable Increment) is the larger development time box (super-sprint) that uses cadence and synchronization to facilitate planning, provide for aggregation of newsworthy value, and provide a quantum unit of thinking for portfolio level consideration and roadmapping. And while continuous integration and system validation is always the goal, the PSI timebox can also provide a forcing function to reduce the risk of deferred integration, and even worse, deferred or slow internal or external customer feedback. In some situations, each PSI is released to the external users, in which case the PSI is also a release. Others enterprises will need to release less or more frequently than the PSI cadence.
Refactoring is a systematic approach to improving the code base without changing observable 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. Refactoring requires that each change made be tested immediately to verify the correct accomplishment of the desired goal.
The Release Management Team is the authority responsible for scheduling, managing and governing synchronized releases (PSIs) across one or more programs or product lines. The primary responsibility of the team is to coordinate and facilitate the delivery of GA, or production ready, software developed by the associated Agile Release Train, whether it be released to marketing, distribution, or deployment into IT operations.
PSI (Release) Planning is the seminal, cadence-based synchronization point of the Agile Release Train (ART). 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 PSI/Release objectives for the next PSI timebox. Typically facilitated by the Release Train Engineer, attendees typically include ALL members of the program and takes place over a one to two-day period. In geographically distributed programs, the event may occur at multiple locations simultaneously. A successful event delivers four primary artifacts: a set of PSI Program Objectives, “SMART” Team PSI Objectives; a PSI Plan, which highlights the new Features, anticipated delivery dates and any other relevant milestones; and a vote of confidence/commitment from the entire program to these objectives.
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 Meetings, Release Management Meetings, the Inspect & Adapt Workshops, and the Scrum of Scrums. They may report into the PMO, or the development organization, and also communicate status to the Release Management Team.
The Roadmap provides a view of the intended deliverables, such as Features, Epics, and other milestones, over a timeline horizon of approximately three to six months. The Program Roadmap is visible to all teams involved in the program as well as stakeholders and customers. The Roadmap typically includes high confidence Feature visibility into the upcoming PSI/Release, medium confidence visibility into the next, and relatively lower confidence thereafter, as business priorities will likely change during that timeframe.
The Scrum/Agile Master is a dedicated team member who has a primary responsibility to help the self-organizing, self-managing team meet its goals and commitments, and continuously improve performance. They understand and teach Scrum and Agile, foster collaboration, implement and enforce Scrum practices, encourage XP inspired technical practices, help identify and eliminate impediments, and help the team constantly improve its performance, including addressing individual performance issues as they arise. The Scrum Master also helps protect the team from outside influences that could disrupt their work flow.
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 Program PSI objectives, 3) providing a simple communication protocol between the teams, management, and business owners, so that management is continuously apprised of the work in process and the current intent of each team on the train.
Stories (user, technical, infrastructure) are the Agile replacement for traditional forms of requirement specifications (the system shall….). Stories are small, independent behaviors that can be implemented incrementally, each of which provides value to the business. Stories are split as necessary so they can be completed in a single iteration. Stories are not requirements, in that they are generally negotiable and thereby represent a statement of intent rather than a contractual (internally or externally) 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. The primary expression of system behavior is the User Story. User stories are user and value centric, as they put the user, not the system, as the target of interest.
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, foster emergent design and architectural flow, assist with understanding interfaces and dependencies, and facilitate team level design decisions. They maintain and evolve an understanding of the implementation framework, Nonfunctional Requirements, and deployment and operational considerations necessary to support current and upcoming user and business needs. In addition, they maintain lightweight models, such as domain and use case models, that are used to illustrate the larger system design and behavior to all stakeholders.
The System Demo occurs every two weeks and provides an aggregate – and integrated – view of 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 purpose of the System Demo is 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 in-process solution. 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 system testing.
A task is the lowest level unit of work in SAFe. During Iteration Planning, teams break stories down into Tasks, the individual actions that are required to deliver a story. Tasks are typically estimated in hours (approx. 2-4-8), assigned to one person and must be delivered in a single iteration. If a Task is too big to complete in a single iteration, then the story is too big and it must be split before proceeding. Tasks provide a way for the team to agree on exactly who is going to do what to complete the Story. Tasking also exposes dependencies within the team, as well as bottlenecks, personnel and resource availability, etc.
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.
Agile Teams are responsible for Defining/Building/Testing stories from their Team Backlog in a series of fixed-length Iterations (sprints), using cadence and synchronization to help manage the variability inherent in software development. Further, they cooperate by integrating their code with that of other teams to build the features and components of larger, higher-value solutions on an Agile Release Train. Agile Teams are also responsible for implementing and executing the basic Agile project management practices (primarily from Scrum), Agile technical practices (primarily from XP), and collaborating, knowledge sharing, and cross training to the benefit of the enterprise.
Team PSI Objectives are a summarized description of the specific business and technical goals that a team intends to achieve in the upcoming PSI. 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 PSI. The aggregation of each team’s objectives becomes the Program PSI 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, Non-Functional 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 the programs goals and objectives.
Weighted Shortest Job First (WSJF)
WSJF is a lean method for determining backlog prioritization (job sequencing) using the cost of delay and remaining job size. This algorithm is applied at PSI boundaries to continuously update program priorities based on current business context, value, development facts, risk, and effort considerations. The formula for WSJF is (User Value+Time Value+Risk Reduction|Opportunity Value)/Job Size. If the team’s job size estimates are updated to include only time remaining, then constant application of WSJF ignores sunk costs, which is a key economic principle of lean.
Last update: 3 February, 2014
© 2010-2014 Leffingwell, LLC. All rights reserved.