Scrum & Agile — Advanced

Scaling Scrum — SAFe and multi-team coordination

Scrum itself is designed for a single team; SAFe (Scaled Agile Framework) addresses the genuinely different problem of coordinating agile practice across multiple teams, programs, and portfolios within larger organizations — introducing additional structural layers (like Agile Release Trains, coordinating multiple teams working toward a shared solution) and roles beyond Scrum's core three. This isn't simply "more Scrum" — scaling agile practice introduces coordination challenges (dependency management across teams, portfolio-level prioritization, architectural alignment) that a single Scrum Team's framework doesn't need to address, which is why SAFe exists as a genuinely distinct framework layered above, rather than simply an extension of, core Scrum. (needs verification — recheck against current source: SAFe's specific structure and role definitions are periodically updated by Scaled Agile, Inc.)

Common Scrum anti-patterns

Advanced-level Scrum understanding includes recognizing common ways teams claim to "do Scrum" while undermining its actual purpose: "Scrum but" patterns (a team runs Scrum's events but skips or waters down key elements — like a Daily Scrum that becomes a status report to a manager rather than a Developer-led inspection/adaptation session, directly undermining Fundamentals' point about the Scrum Master's non-directive role), mini-waterfall Sprints (a Sprint internally structured as sequential design-build-test phases rather than genuinely iterative, cross-functional collaborative work throughout), and Product Owner absenteeism (a Product Owner insufficiently available to the team, undermining the Product Backlog's responsiveness and the team's ability to get timely clarification — directly working against the "customer collaboration" value from the Agile Manifesto, Overview). Recognizing these patterns is frequently tested through scenario questions describing a team's actual practice and asking whether it genuinely reflects Scrum, not just its surface-level ceremonies.

Self-management — a core but often misunderstood Scrum concept

Scrum explicitly expects the Developers to be self-managing — deciding internally who does what, when, and how, rather than being directed by the Scrum Master or an external manager. This connects directly to the Scrum Master's non-directive role (Fundamentals): self-management isn't simply an absence of management, it's a deliberate structural choice reflecting the empirical belief (Fundamentals) that the people closest to the actual work are best positioned to make real-time decisions about how to perform it, with transparency and inspection mechanisms (the Daily Scrum, Sprint Review) providing the necessary oversight and course-correction without requiring top-down direction.

Connecting Scrum's mechanics back to agile values under scaling pressure

The advanced-level synthesis, particularly relevant when comparing Scrum to scaled frameworks like SAFe: as organizations scale agile practice across more teams, there's a genuine risk of the coordination overhead (necessary at scale) gradually reintroducing the kind of process-heavy, top-down structure the Agile Manifesto's values originally pushed against (Overview) — advanced practitioners need to actively guard against this tension, ensuring that scaling mechanisms (like SAFe's additional structure) genuinely serve coordination needs without undermining the individual Scrum Team's self-management and the broader agile values the entire framework exists to serve. This tension — between necessary coordination at scale and preserving agile's core values — is a genuinely advanced, actively debated topic in agile practice, not a settled question with one universally correct answer.