Inside the Foundations module
Foundations is the module every other campaign assumes you have finished. It covers what Scrum is, why it exists, and where the framework stops being useful, starting with empiricism and the three pillars: transparency, inspection, and adaptation. Rather than presenting these as abstract theory, the lessons connect each pillar to a concrete failure mode you can recognize, a status update that hides bad news is a transparency failure, a Sprint Review with no real feedback loop is an inspection failure, and a retrospective with no changed behaviour afterward is an adaptation failure.
From the pillars, the module moves to the five values, commitment, courage, focus, openness, and respect, and treats them as observable behaviour rather than posters on a wall. A short game asks you to match real team situations to the value being tested, which forces you to notice values in the moment instead of reciting them afterward. The module then covers the three accountabilities and the five events at a glance, building toward the fast diagnostic used throughout the rest of the course: ask a team to state its Product Goal, Sprint Goal, and Definition of Done in one sentence each, and you learn immediately whether the artifacts are doing real work or just decorating a board.
A significant part of Foundations is dedicated to boundaries: when Scrum is the right tool, when it is not, and how it differs from Agile broadly and from Kanban specifically. This matters because a large share of the frustration people bring to Scrum comes from applying it to well-understood, repetitive work where a flow-based approach would serve better, or from expecting Agile principles and Scrum's specific rules to be interchangeable. Getting this distinction right early prevents the common interview mistake of conflating the two, and it prepares you for the flow-based and scaling modules later in the curriculum.
The module closes with common misconceptions and a walkthrough of how to actually read the Scrum Guide so you can catch, on your own, when a team's practice has drifted from the text. Two checkpoints and a set of scenario games force you to apply the pillars and values under pressure rather than just recognize them on a multiple-choice question, which is what the Foundations quiz at the end is built to test.
Mistakes teams make with this material
Treating Scrum's specific rules, like the Sprint length or the Daily Scrum, as universal Agile principles. Agile is a set of values and principles; Scrum is one particular, deliberately minimal framework that implements some of them.
Forcing Scrum onto support queues or maintenance work where the requirements are already known and the work arrives continuously. That is Kanban territory, and forcing Sprint boundaries onto it usually just adds overhead.
Being able to name commitment, courage, focus, openness, and respect without recognizing the moment a team is violating one, for example, silently absorbing scope instead of raising it, which is a courage and transparency failure at once.
Running the Daily Scrum, Sprint Review, or Retrospective as a scheduled meeting without asking what is being inspected and what will change as a result, which turns real adaptation into a fifteen-minute status report.
Questions people ask
What is the actual difference between Scrum and Agile?
Agile is a mindset described by four values and twelve principles, favoring people, working software, collaboration, and responding to change. Scrum is one specific, lightweight framework, with defined roles, events, and artifacts, that helps a team live out some of those values. You can be Agile without using Scrum, and you can technically run Scrum's ceremonies without being Agile in spirit.
When should a team choose Kanban instead of Scrum?
When the work is continuous rather than plannable in fixed batches, support tickets, incident response, or a steady stream of small requests, a pull-based flow system with WIP limits usually serves better than Sprint boundaries. Scrum fits complex product work where a team benefits from a fixed timebox to focus, plan, and inspect.
Why does the module spend so much time on the three pillars?
Because nearly every anti-pattern later in the curriculum traces back to a pillar failure. Hidden information breaks transparency, a Sprint Review with no real stakeholder feedback breaks inspection, and a retrospective that never changes anything breaks adaptation. Understanding the pillars gives you one diagnostic that works across every event.