11.1 Scaled Agile Frameworks

11.1 Scaled Agile Frameworks

When an organization expands Agile beyond a single cross-functional team, standard team-level frameworks like Scrum and Kanban encounter structural limitations. Enterprise scaling requires coordinating multiple teams, aligning portfolio investments with strategy, managing shared architectural dependencies, and maintaining consistent value delivery. On the PMI-ACP exam, candidates are tested on the underlying principles, governance constructs, and operational mechanisms of the primary scaling frameworks: Scaled Agile Framework (SAFe®), Large-Scale Scrum (LeSS), Disciplined Agile (DA), Nexus, and Scrum@Scale.

---

Scaled Agile Framework (SAFe®)

The Scaled Agile Framework (SAFe®) is an enterprise knowledge base of proven, integrated principles, practices, and competencies for scaling Lean, Agile, and DevOps. SAFe operates across four primary configuration levels: Essential, Large Solution, Portfolio, and Full SAFe.

Key SAFe Constructs

• Agile Release Train (ART): The foundational mechanism of SAFe. An ART is a long-lived, self-organizing team of Agile teams (typically 50 to 125 individuals) along with key stakeholders that plans, commits, and executes together on a synchronized cadence.
• PI Planning: A cadence-based ART event at the start of a Planning Interval (PI). In the common two-day format, all teams on the train review the vision, estimate user stories, identify cross-team dependencies on an ART planning board, address risks, and establish committed and uncommitted PI Objectives.
• System Demo: A primary ceremony occurring at the end of every iteration across the ART where the integrated work of all teams is demonstrated to business owners and stakeholders. This provides immediate empirical feedback on solution health.
• Release Train Engineer (RTE): Is a servant leader and ART coach. The RTE facilitates ART events and execution, supports risk and dependency management, and helps the train improve.

---

Large-Scale Scrum (LeSS)

Developed by Craig Larman and Bas Vodde, Large-Scale Scrum (LeSS) takes a minimalist, 'less is more' approach to enterprise scaling. Rather than adding management layers or complex processes, LeSS applies standard single-team Scrum rules directly to multi-team environments.

Core LeSS Rules

• One Product Backlog & One Product Owner: Regardless of how many teams are working on the product (up to 8 teams in standard LeSS), there is only one unified Product Backlog and one single Product Owner prioritizing features.
• Shared Definition of Done (DoD): All teams contribute to a single, integrated, potentially releasable product increment at the end of every Sprint. While individual teams may expand their team-specific DoD to include stricter internal standards, they must all satisfy the shared organizational DoD.
• LeSS Huge: For organizations with more than 8 teams (often thousands of engineers), LeSS scales into LeSS Huge. This structure introduces Requirement Areas managed by Area Product Owners (APOs), while maintaining alignment under a single corporate Product Owner.

---

Disciplined Agile (DA)

Acquired by the Project Management Institute (PMI), Disciplined Agile (DA) is a hybrid process-decision toolkit that puts people and context first. Rather than prescribing a rigid framework, DA provides guidance on tailoring processes based on situational needs.

Core Disciplined Agile Concepts

• 'Choose Your WoW' (Way of Working): The foundational philosophy of DA. Teams evaluate their unique project context (team size, geographic distribution, regulatory compliance, domain complexity) to select the most effective lifecycle.
• Process Blades: Modular organizational capabilities that address specific enterprise functions. Examples include Enterprise Architecture, Portfolio Management, Finance, Legal, Governance, and Continuous Improvement.
• Supported Lifecycles: DA explicitly supports six distinct lifecycles: Agile (Scrum-based), Lean (Kanban-based), Continuous Delivery Agile, Continuous Delivery Lean, Exploratory (Lean Startup model), and Program (for large-scale teams).

---

Nexus Framework

Developed by Ken Schwaber and Scrum.org, Nexus is an operational framework specifically designed to scale Scrum for 3 to 9 cross-functional teams working on a single Product Backlog to build a single product.

Nexus Components

• Nexus Integration Team (NIT): A specialized team accountable for ensuring that an integrated, releasable product increment is produced at least once per Sprint. The NIT consists of the Product Owner, a Scrum Master, and one or more Nexus Integration Team Members skilled in integration tools and architecture.
• Nexus Events: Nexus overlays standard Scrum ceremonies with scaling events:
  • Nexus Sprint Planning: Representatives from all teams review backlog items to identify cross-team dependencies and allocate work.
  • Nexus Daily Scrum: Representatives meet daily to review integration progress and identify cross-team blockers.
  • Nexus Sprint Review & Retrospective: Held jointly across all teams to inspect the integrated product and shared process improvements.

---

Scrum@Scale

Created by Jeff Sutherland (co-creator of Scrum), Scrum@Scale extends the standard Scrum framework organically through a modular architecture based on two primary cycles: the Scrum Master Cycle (how work gets delivered) and the Product Owner Cycle (what gets delivered).

Key Scrum@Scale Structures

• Scrum of Scrums (SoS): A group of cross-functional teams that operates as a release team. The SoS elects a Scrum of Scrums Master (SoSM) responsible for facilitating cross-team alignment and removing impediments.
• Executive Action Team (EAT): Fulfills Scrum Master accountabilities for the agile organization. The EAT creates and improves the agile operating system and has authority to resolve impediments that teams or Scrum of Scrums groups cannot remove.
• Executive MetaScrum (EMS): Operates as the ultimate Product Owner group, responsible for setting enterprise strategy, aligning product vision, and allocating resources across trains or clusters.

---

Enterprise Scaling Framework Comparison

---

PMI-ACP Exam Scenario Focus

When answering scaling questions on the PMI-ACP exam, apply these situational rules:

1. Dependency Resolution: If cross-team dependencies block progress, look for solutions that promote direct peer-to-peer team communication (e.g., Nexus Daily Scrum, SAFe PI Planning, or Scrum of Scrums) rather than escalating to traditional project managers.
2. Backlog Integrity: In LeSS and Nexus, multiple teams working on one product use a single Product Backlog. Apply the named framework's actual backlog structure rather than generalizing that rule to every scaling approach.
3. Impediment Removal: If organizational policies block team agility at scale, framework mechanisms like the Executive Action Team (EAT) in Scrum@Scale or the Release Train Engineer (RTE) in SAFe represent the proper channels for systemic resolution.