PSM I Scrum Theory: Empiricism, the Three Pillars and the Scrum Values

The 2020 Scrum Guide defines Scrum as a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems. It is a framework, not a methodology, a project-management standard or a complete process: it does not prescribe engineering practices, estimation techniques or board layouts.

Three ideas from the Guide's definition are tested again and again:

• Purposefully incomplete. Scrum defines only the parts needed to put Scrum theory into practice. The gaps are deliberate, not something a future edition will fill and not rules the Scrum Master is expected to invent. The framework draws on the collective intelligence of the people using it.
• Rules for relationships, not instructions for tasks. Instead of giving people detailed instructions, Scrum's rules guide their relationships and interactions. Within the framework a team can use many different processes, techniques and methods, such as user stories, Kanban boards, test-driven development or pair programming.
• It exposes what already exists. Scrum wraps around existing practices, or makes some of them unnecessary, and makes visible how effective the current management, environment and work techniques really are, so that improvements can be made. If, after a few Sprints, a team's dependence on another department becomes painfully obvious, Scrum did not create that dependence; it made it visible.

Scrum is meant for complex work, where outcomes cannot be reliably predicted in advance. That is why it relies on learning from real results rather than on a detailed upfront plan or design.

The Guide summarizes Scrum as a repeating cycle that needs a Scrum Master to foster an environment in which:

1. a Product Owner orders the work for a complex problem into a Product Backlog;
2. the Scrum Team turns a selection of that work into an Increment of value during a Sprint;
3. the Scrum Team and its stakeholders inspect the results and adjust for the next Sprint;
4. the cycle repeats.

Each step belongs to someone different. The Scrum Master is not accountable for ordering the Product Backlog or for building the Increment; the Scrum Master's accountability is creating the conditions for the cycle to work. The step organizations most often drop is the third: when what the team learns from one Increment never changes what it does next, it is producing Increments without inspecting and adjusting, and the cycle that makes Scrum empirical is broken.

The details of accountabilities, events and artifacts are covered in the next lessons of this domain: the Scrum Team and its accountabilities, the Sprint and the Scrum events, and the artifacts with their commitments.

Empiricism asserts that knowledge comes from experience and that decisions are made on the basis of what is observed. Scrum is founded on empiricism together with lean thinking, which reduces waste and focuses on the essentials.

In practice, empiricism means a team decides what to do next by looking at real evidence: the working Increment it has just built, how users and stakeholders respond to it, and the actual state of its work. It does not mean conforming to a plan that was made before any of that evidence existed.

Lean thinking is the second foundation. It asks whether each activity adds value. Rework caused by late feedback and features nobody uses are typical waste. Lean thinking never justifies removing a part of Scrum itself, though: every Scrum element exists to create transparency or an opportunity to inspect and adapt, and those are not waste even when a particular instance finds nothing.

Scrum uses an iterative, incremental approach to optimize predictability and to control risk. The Guide does not define the two words; in common teaching usage, iterative means revisiting and improving earlier work as you learn, and incremental means each Sprint adds a usable piece of the product to what already exists.

• Risk control: a wrong assumption shows up after one short Sprint, while it is still cheap to correct, instead of at a final integration or release.
• Predictability: each Sprint produces real data about what the team actually delivers, and forecasts built on that data become more reliable over time. Predictability comes from evidence gathered Sprint by Sprint, not from more detailed planning upfront.

It is the opposite of a sequential, phase-gated, plan-driven approach. Any arrangement that tries to settle everything before evidence exists brings back the risk that short cycles are meant to control.

Scrum Theory says Scrum engages groups of people who collectively have all the skills and expertise to do the work, and who share or acquire those skills as needed. The skills belong to the group, not to each individual: nobody has to be able to do everything, but the team as a whole must not depend on one person or on borrowing skills from outside each Sprint.

When only one member holds a skill the work needs, the Scrum-consistent response is to spread it, for example by pairing so others learn while the work gets done. Workarounds that keep the work flowing through that one person may help this Sprint, but they leave the single point of failure in place. Who belongs on the team and what cross-functional means in detail is covered in the Scrum Team lesson.

The Guide also says it uses the word Developers to simplify, not to exclude. Scrum started with software but is used in many domains: research, marketing, education, operations and more. Anyone doing the work of creating the Increment is a Developer, whatever their job title.

The three pillars that uphold empiricism are transparency, inspection and adaptation. They form a chain: transparency enables inspection, and inspection enables adaptation. If an earlier link breaks, everything after it fails too.

Notice the two different judgments: inspection without transparency is misleading and wasteful (you are inspecting a false picture), while inspection without adaptation is pointless (you looked, but did nothing with it). Note too what is inspected and why: the Scrum artifacts and progress toward agreed goals, so that undesirable variances or problems are detected early.

The Scrum events are where the pillars happen. Each event is a formal opportunity to inspect and adapt, and the events are designed to provoke change. Scrum places four formal events for inspection and adaptation inside a containing event, the Sprint, and together the five give inspection its cadence. Leaving one out loses an opportunity to inspect and adapt, however experienced the team is. The timing, purpose and attendees of each event are covered in the lesson on the Sprint and the Scrum events.

To diagnose a pillar failure, follow the chain from the start and find the first link that breaks. The earliest failure is the root cause, because the later pillars depend on it.

• Transparency failing: the real state of the work is hidden or wrong. A task board shows items in progress long after they stalled, an artifact shown to stakeholders differs from the one the team actually works from, or something is called Done that does not meet the Definition of Done. Every inspection that follows is based on an inaccurate picture, so the adaptations that follow are wrong too, even though the events still run on schedule.
• Inspection failing: the information is visible but nobody examines it often or carefully enough, so variances grow until it is too late.
• Adaptation failing: the team inspects well and even records the findings, but nothing changes. Useful Sprint Review feedback that never alters the Product Backlog is the classic sign.

Adaptation also has a timing rule: a Scrum Team is expected to adapt the moment it learns something new through inspection. If the Developers find mid-Sprint that a design choice is not holding up, they change course straight away: adaptation is not saved up for a later event, and the Sprint Backlog is the Developers' own plan. It is updated as soon as they know, and if the scope needs to change, it is clarified and renegotiated with the Product Owner. The Sprint is not extended, and the Sprint Goal stays the target.

The five Scrum Values are commitment, focus, openness, respect and courage. The Guide says the successful use of Scrum depends on people becoming more proficient in living these values, not in running the events or using the artifacts mechanically.

Common traps list words that sound right but are not Scrum Values: transparency (a pillar), trust (an outcome of living the values), collaboration and simplicity. Do not confuse the values with the pillars: courage, focus, openness, respect and commitment are values; transparency, inspection and adaptation are pillars.

When a behavior could match several values, choose the one the Guide's description fits most directly. Openness is about being open about work and challenges; courage is about doing the right thing under pressure; respect is about treating people as capable and independent.

The Scrum Values give direction to the Scrum Team's work, actions and behavior, and when the team and the people it works with embody them, the empirical pillars come to life, building trust. The values are what make transparency, inspection and adaptation possible between real people.

• Without openness and courage, transparency fails. If people expect blame for raising problems, they stop raising them, and every inspection rests on a false picture.
• Decisions should reinforce the values, not diminish them. The Guide expects the decisions made, the steps taken and the way Scrum is used to support the values. Measures that set team members against each other, for example, undermine commitment to shared goals and to supporting each other.
• Values are learned through practice. The Guide says team members learn and explore the values as they work with the Scrum events and artifacts. They grow through doing Scrum, from the start, rather than being added once the mechanics are mastered.
• Values extend beyond the team. Respect and openness apply to stakeholders and the wider organization too; the pillars come to life when the Scrum Team and the people it works with embody them.

No. The Scrum framework, as described in the Guide, is immutable. Implementing only parts of Scrum is possible, but the result is not Scrum: Scrum exists only in its entirety. At the same time it works well as a container for other techniques, methodologies and practices.

The Guide's purpose section explains why: each element of the framework serves a specific purpose that is essential to the overall value of Scrum. Changing its core design or ideas, leaving out elements or not following its rules covers up problems and limits the benefits of Scrum, and can even make it useless. Good delivery figures do not prove an element was unnecessary; removing it may only be hiding the problems it would have exposed.

The test is simple: a practice that sits inside the framework is fine; a practice that replaces or removes a Scrum element is not. User stories and story points are not Scrum elements, so neither using nor dropping them affects whether a team does Scrum. Missing a Retrospective does. The Guide also leaves out tactics, such as particular estimation or backlog techniques, on purpose, because they are context sensitive and vary widely between uses of Scrum.