Scrum & Agile — Fundamentals
The Agile Manifesto's twelve principles
Beyond the four values (Overview), the Agile Manifesto includes twelve supporting principles — among the most frequently referenced: prioritizing early and continuous delivery of valuable software; welcoming changing requirements, even late in development; delivering working software frequently, with a preference for shorter timescales; sustaining a constant pace of work indefinitely (avoiding unsustainable overtime/crunch); and regularly reflecting on how to become more effective, then adjusting accordingly (directly underlying Scrum's Sprint Retrospective, Intermediate). These principles collectively describe why agile teams work the way they do — Scrum's specific mechanics (Intermediate/Advanced) exist to operationalize these principles into a concrete, repeatable framework, not as an arbitrary separate structure.
Scrum's three roles
Scrum defines exactly three roles (frequently tested as a set, since candidates sometimes incorrectly add roles like "project manager," which doesn't exist within Scrum's framework): the Product Owner (responsible for maximizing product value, primarily by managing the Product Backlog — deciding what gets built and in what priority order), the Scrum Master (responsible for establishing Scrum as defined in the Scrum Guide, helping everyone understand Scrum theory and practice, and removing impediments to the team's progress — a facilitative and coaching role, not a traditional command-and-authority project-manager role), and the Developers (the people doing the actual work of creating a usable increment each Sprint — this term applies broadly to whoever is doing the building work, not narrowly to software engineers alone). Together, these three roles plus the people fulfilling them constitute the Scrum Team — a single, cohesive unit without sub-teams or hierarchies within it.
Why the Scrum Master isn't a traditional manager
A frequently tested and commonly misunderstood point: the Scrum Master role is explicitly not equivalent to a traditional project manager — the Scrum Master doesn't assign tasks, direct the team's day-to-day work, or hold authority over what gets built (that's the Product Owner's domain for prioritization, and the Developers' domain for how work gets done). Instead, the Scrum Master serves the Scrum Team by coaching them in self-management and cross-functionality, removing impediments, and ensuring Scrum events happen and are productive — a servant-leadership orientation conceptually similar to PMP's own leadership principle (this academy's PMP technology), though Scrum's framework makes this role distinction more structurally explicit than PMP's broader project-management framing does.
Empiricism — the theoretical foundation beneath Scrum's mechanics
Scrum is explicitly built on empiricism — the idea that knowledge comes from experience and decisions should be based on what is observed, not solely on upfront prediction — operationalized through three pillars: transparency (significant aspects of the process must be visible to those responsible for the outcome), inspection (frequently and diligently inspecting Scrum artifacts and progress toward goals, to detect problematic variances), and adaptation (adjusting the process or the material being worked on as soon as possible when inspection reveals a deviation). Scrum's specific events (Intermediate) each exist substantially to enable one or more of these three pillars — understanding this connection is what makes Scrum's event structure feel like a coherent system rather than an arbitrary set of meetings.