Study smarter with Fiveable
Get study guides, practice questions, and cheatsheets for all your subjects. Join 500,000+ students with a 96% pass rate.
When organizations grow beyond a single Scrum team, they face a fundamental challenge: how do you maintain Agile's core values—collaboration, adaptability, and continuous delivery—while coordinating dozens or even hundreds of people? This is where scaling frameworks come in, and understanding them is essential for any Agile certification exam. You're being tested on your ability to recognize which framework fits which organizational context, how each one balances autonomy versus alignment, and what trade-offs come with different scaling approaches.
These frameworks aren't just theoretical—they represent real solutions to the coordination problems that derail large projects. Whether an exam question asks about synchronizing multiple teams, managing cross-team dependencies, or choosing between a prescriptive versus flexible approach, you need to understand the underlying principles each framework embodies. Don't just memorize framework names and their creators—know what problem each one solves and when you'd recommend one over another.
Some scaling frameworks provide comprehensive, structured approaches with defined roles, ceremonies, and organizational layers. These work best when organizations need clear guidance and consistent practices across many teams.
Compare: SAFe vs. DA—both address enterprise-scale Agile, but SAFe provides a more prescriptive structure while DA offers a flexible toolkit. If an FRQ asks about helping an organization choose their own way of working, DA is your answer; if it asks about synchronizing multiple teams with defined ceremonies, think SAFe.
These frameworks extend Scrum's core practices to multiple teams while preserving its empirical, inspect-and-adapt foundation. They assume teams already know Scrum and focus on coordination mechanisms.
Compare: LeSS vs. Nexus—both scale Scrum with minimal overhead, but LeSS emphasizes a single Product Owner for all teams while Nexus introduces an Integration Team role. Nexus is more explicit about integration practices; LeSS trusts teams to self-organize around dependencies.
Not every scaling approach is a full framework. Some are specific techniques for cross-team coordination, while others describe organizational culture patterns rather than prescriptive processes.
Compare: Scrum of Scrums vs. Spotify Model—SoS is a specific coordination meeting technique, while Spotify describes an entire organizational culture. Exam questions may test whether you recognize that the Spotify Model isn't actually a framework to "implement" but rather a case study in organizational design.
| Concept | Best Examples |
|---|---|
| Prescriptive enterprise scaling | SAFe, Disciplined Agile |
| Minimalist Scrum extension | LeSS, Nexus |
| Single Product Backlog across teams | LeSS, Nexus |
| Coordination meeting technique | Scrum of Scrums |
| Toolkit/choose-your-own approach | Disciplined Agile, Spotify Model |
| Defined organizational levels | SAFe (4 levels), LeSS Huge (Area structure) |
| Cultural/autonomy focus | Spotify Model |
| Fractal/network scaling | Scrum@Scale |
Which two frameworks most emphasize maintaining a single Product Backlog across all teams, and why does this matter for reducing dependencies?
If an organization wants guidance but needs flexibility to choose practices based on their specific context, which framework would you recommend—SAFe or Disciplined Agile? Explain the key difference.
Compare and contrast LeSS and Nexus: what coordination mechanism does Nexus add that LeSS deliberately avoids, and what does this reveal about their different philosophies?
Why is it technically incorrect to say an organization "implemented the Spotify Model"? What distinguishes it from frameworks like SAFe or LeSS?
An FRQ describes an organization with 15 Scrum teams struggling to coordinate dependencies. Which frameworks or techniques would you recommend they evaluate, and what questions should they ask to choose between them?