Agile was designed to optimize delivery of user-facing features from a single team. Larger value delivery efforts require greater orchestration; more input from a wider, cross-functional range of contributors; and additional consideration for increased complexity and duration.
Candidates for scaled agile approaches include ....
Multiple teams with common delivery goals.
Solutions with substantial architectural complexity and/or multiple components.
Programs which must provide significant longevity and sustainability.
To succeed at agile at scale, it is recommended that organizations ...
Establish a scaled agile methodology that prioritizes team coordination. (See a listed of established scaled agile methodologies at the bottom of this page.)
Continuously invest in the architectural runway,
Decompose features (functional epics and stories) horizontally into common services and variability mechanisms that promote reuse.
Clarify and prioritize architecturally significant requirements.
Use test-driven development and continuously focus on verification.
Most scaled-agile frameworks are an elaboration of the roles, activities, and artifacts of single-team Scrum. For example, where a Scrum team works off of a single product backlog (broken down into stories), multiple teams share a program backlog which defines higher-level features and system-level capabilities, usually written in terms of agile epics. Where single teams deliver value in potentially shippable product increments (PSIs), multiple teams coordinate to deliver value in program increments (PIs). The term for the team-of-agile-teams in program-level agile varies based on the framework, but this collaboration is often referred to as a release train.
A release train is a long-lived, virtual organization of up to 12 agile teams (i.e., up to 125 individual contributors) that plans, commits, and executes together under a common mission and architectural guidance, using a single program backlog. Whereas individual agile teams work in sprints to deliver value, release trains iterate in program increments (lasting, for example, 5 sprints, or 10 weeks). Every team within the release train operates on synchronized sprint boundaries within the program increment.
Like a single agile team is made cross-functional in order to eliminate or minimize dependencies and hand-offs between functional silos, a single release train needs be sufficiently cross-functional to minimize dependencies and hand-offs between the teams. It is important to avoid creating teams on the basis of platform, architecture layer, programming or spoken language, or location boundaries. Create teams instead based on value delivery (features or components/products).
Feature teams will develop T-shaped skills and minimize dependencies but will require architectural governance. Component (or product) teams will maximize technology reuse and can best address critical non-functional requirements but will require content coordination. A release train may be composed of, say, four feature teams and two component teams.
To assist with integration, release trains sometime rely on the services of an additional system team.
Additional or substitute activities are required at the program level in order to keep teams cross-functional, manage (or preferably avoid) dependencies between teams, and plan integration.
Program Backlog Refinement replaces Product Backlog Refinement. The main difference here is that program backlog is defined in terms of high-level requirements (usually epics) with high-level sizing provided by product management and solution architects and/or tech leads.
Roadmap Planning enables an organization to forecast the delivery items. The roadmap is not a commitment.
Innovation and Planning (IP) Sprint (aka "Iteration 0") - A sprint within the program increment that is dedicated to making sure the subsequent iterations are a success. This includes all program increment pre-planning activities (including backlog refinement) as well as team time dedicated to foundational pieces (building architecture and data models, business process models; setting up environment; training) needed to enable the functional stories.
The output of roadmap planning is mapping of high-level program backlog items to upcoming program increments for the next 6 to 18 months. Note that these are not necessarily delivery commitments, but guides in long-range planning.
Capacity planning and a stable program velocity provides the boundaries for how much work can be planned into a program increment.
It can take two weeks for a program to produce a 6-month release plan.
Prioritized based on business value and dependency.
Sized using story points, avoiding precision. Size reflects input from everyone in the cross-functional team.
Owned by an individual. This person is often the one responsible for implementing the item, but needs to at least be a single person who makes sure the item comes to completion and reports on it on a day-to-day basis.
Incorporated into an overall plan (what to get done when). Items are placed into iterations. This doesn’t need to go out all the way to a deadline. The number of iterations needed might change as the team proceeds and better understands their velocity.
Executive Planning produces vision and strategy, which are inputs into ...
Roadmap Planning, which combines the executive vision and strategy with the items in the program backlog, and produces a forecast (roadmap). The forecast is a mapping of high-level program backlog items to planned program increments (releases); it is not a delivery commitment. Roadmap Planning happens about every 6 months and can take up to two weeks for large programs. The forecast for the coming program increment is the release backlog, which is an input into ...
Program Backlog Refinement ...
Program Increment Planning, which breaks down any epics on the release backlog into sprint-sized stories. Stories must be written in terms of the value they contribute towards the overall objectives, and have clear definitions of "done". For this reason, product owners skilled in splitting stories and defining done are a key part of Program Increment Planning. Release Planning happens on whatever cadence the organization decides, but usually quarterly, and takes approximately two days.
Sprint Planning, in which the team breaks down the stories into tasks, as necessary.
Take an economic view.
Apply systems thinking.
Assume variability and preserve options.
Build incrementally with fast, integrated learning cycles.
Base milestones on objective evaluations of working systems.
Visualize and limit WIP, reduce batch sizes, and manage queue lengths.
Apply cadence and synchronize with cross-domain planning.
Unlock the intrinsic motivation of knowledge workers.
Decentralize decision-making.
Supporting all of the roles and activities, below, are ...
DevOps
System Team.
Shared Services.
SAFe offers constructs for both program-level agile and portfolio-level agile. Program-level constructs assist in the coordination of multiple teams to a common set of objectives and delivery of value. Portfolio-level constructs redress some of the traditional enterprise constraints that create obstacles to an enterprise agile transformation.
SAFe Agile Teams include all of the roles and activities as a Scrum Team. To align multiple teams to a common vision and single program backlog requires more coordination and includes the following roles.
Product Manager (Chief Product Owner)
Release Train Engineer (Master Scrum Master) - The RTE is a servant leader and coach for the Agile Release Train. This person is responsible for running the Scrum of Scrums and facilitates the train's processes, events, and execution; escalates impediments; and helps manage risk, value delivery, and continuous improvement.
System Architect.
Business Owners.
Build roadmap
Refine program backlog
Prepare for Program Increment (PI) Planning
Plan Program Increment (PI) - PI Planning is a two-day event, occurring during the final sprint of the previous PI (the IP sprint).
The input to PI planning is the vision (per the Product Manager) and prioritized program backlog; the outputs are PI objectives (team-level and program-level) and the program board; and the goal of PI Planning is always, always, always alignment to a common mission.
During PI Planning, the following occurs:
The executive sponsor provides the business context and upcoming strategic objectives.
The Product Manager (Chief Product Owner) presents the vision, prioritized features, and anticipated benefits.
The System Architect presents the architecture, common frameworks, agile tooling, and/or engineering practices.
The Release Train Engineer (Master Scrum Master) explains the planning process and reviews the purpose (alignment) and agenda.
Agile teams now ...
Calculate their capacities for the first four iterations of the PI.
Populate their individual product backlogs with features and feature-level enablers from the program backlog.
Break them into stories (if they haven't been broken down already).
Draft plans and identify risks and impediments.
Write out the team's PI objectives (which should encompass the features selected). Identify stretch objectives. (Stories in stretch goals should count against the capacity.)
By the end of PI Planning, the team should have populated the first four iterations of the PI with stories of points totally no more than 70% of the capacity of each sprint.
Repeat #5 on day two.
Business Owners assign business value to team PI objectives (relative value, 1-to-10, within each team).
Place all remaining risks in a ROAM grid. (Categorize them as resolved, owned, accepted, or mitigated.) See if anyone can own, help mitigate, or resolve the unresolved ones.
RTE facilitates teams in presenting and adjusting final plans, risk, and impediments within the entire release train.
Take a confidence vote (fist-to-five) at the team level and the program level.
Everyone participates in a retrospective to help improve PI planning going forward.
Execute the PI.
Innovation and Preparation Sprint
Inspect and Adapt Workshop (PI Retrospective) - 4 hours
System Demo - At the end of a PI, the release train teams demo the integrated solution to the Business Owners and other program stakeholders. This demo is typically run from the staging environment (or the nearest proxy), and is facilitated by the Release Train Engineer. Completed features should be presented by the ones who know it best. Incomplete features can be demo'd when feedback is needed.
Quantitative Measurement - At the end of the demo, the Business Owners are asked to estimate the value achieved of each team's objectives, relative to the planned value that the Business Owners assigned the objectives during PI Planning.
Retrospective and Problem Solving - Attended by everyone in the ART.
Root cause analysis - Ask the "5 whys" and break down causes into categories of people, process, tools, program, and environment. Dot-vote the root causes, looking for the one 20% of the root causes that causing 80% of the problems.
Release any time.
Program Backlog - Contains features and enablers.
PI Planning Calendar - The calendar can be set a year in advance. But this is only to schedule the PI activities, not to commitment features to the roadmap.
Program Increment Objectives - Objectives are summaries, contextualized in terms of business value), of what each team intends to deliver in the upcoming PI. An objective can be an aggregation of features, stated in more concise terms; readiness for a milestone; or enablers needed to support the implementation. During PI Planning, Business Owners assign relative value to each objective stated by the team.
Program Increment
If the solution is sufficiently complex or the enterprise significantly large, SAFe provides a construct between the program level and portfolio level: value stream. Roles at the value stream level include Solution Manager, Value Stream Engineer, and Solution Architect.
The number of levels coordination needed varies with the complexity of the solutions being developed and the size of the organization itself. At the portfolio/enterprise-level requires the following roles:
Portfolio Manager.
Enterprise Architect.
Portfolio Epic Owners.
Master Scrum Master - Facilitates the overarching program and release planning process.
Solution Architect - Looks over the entire program from architectural and technical vision, how to get the work done.
Where an agile program may be constrained by the dictates of a non-agile enterprise (e.g., budgeting models, dependencies on waterfall-driven projects), a truly agile enterprise recognizes that change and delivery of value is constant. There are no projects in enterprise agile--only constant change organized around value streams. For simplicity's sake, all multi-team agile frameworks are described on this website as program-level agile, whereas frameworks that address the philosophical shift required of an enterprise are referred to as portfolio-level agile.
For more on specific roles, activities, and artifacts in scaled agile, see the pages for the individual scale-agile frameworks:
What are the differences between them? Interesting conversation here.
Video [free]: "A Journey Through the Agile Lifecycle" by Sally Elatta.
Article [free]: "10 Best Practices for Achieving Agile at Scale"