Empiricism and the three pillars

Scrum rests on empiricism and lean thinking, which the 2020 Guide names as its two foundations. Empiricism means a team decides what to do next from what it has already observed, and earlier editions of the Guide called that empirical process control. Three pillars make empiricism work in practice. They are transparency, inspection and adaptation, and the five events exist to enact them.

Empiricism and lean thinking

Empiricism asserts that knowledge comes from experience and that decisions follow from what is observed. Lean thinking reduces waste and focuses on the essentials. The Guide names both, because each one alone produces a recognisable failure.

Empiricism alone justifies endless inspection, so an organisation can fill a calendar with defensible review meetings that leave no time to change anything. Lean thinking is the constraint that keeps the loop cheap, which is why the events are timeboxed and why there are five of them rather than fifteen. Lean thinking alone strips waste from a process nobody has checked against reality, which produces an efficient machine for building the wrong product.

Transparency

Transparency comes first, because the other two pillars depend on it. The process and the work must be visible to the people doing the work and to the people receiving it. Visibility alone is not enough, because both sides need a shared standard for what they are seeing, which is why the Definition of Done belongs to transparency as much as to delivery. Low transparency leads to decisions that lower value and increase risk.

What transparency requires is that an artifact be what it claims to be. A backlog for a payments API that leaves out the compliance work everyone knows is coming is not transparent however neatly it is published, and neither is an Increment called Done that nobody could release. This is why each artifact carries a commitment, since the Product Goal, the Sprint Goal and the Definition of Done each give their artifact a standard it can be measured against.

Inspection

A shared standard is what makes inspection possible. Scrum artifacts and progress toward agreed goals are inspected frequently and diligently, to detect variances or problems early. Inspection is not continuous supervision, because it happens at the events, which is why each event has a fixed cadence. That cadence gives one inspection point per artifact per Sprint, plus a daily one for the Developers, so a wrong turn costs at most one cycle. A data pipeline team on two week Sprints inspects its Increment often enough to find a broken schema change within a fortnight at worst, while the same mistake inside a quarterly review has three months of further work sitting on top of it.

Inspection without transparency misleads, because the thing being inspected does not reflect reality. A board showing two items marked Done that nobody could release gives the Sprint Review something to look at and nothing to learn from.

Adaptation

Inspection on its own changes nothing. When it shows that something has deviated outside acceptable limits, the Scrum Team adjusts the process or the material being worked on, and the Guide asks for that adjustment as soon as possible to minimise further deviation. Adaptation becomes harder when the people involved are not empowered or self-managing, which is why this pillar depends on how the organisation is arranged as much as on the team.

Inspection without adaptation is waste in the exact lean sense, because the cost of the meeting was paid, the problem was seen and nothing downstream is any different. A Retrospective producing a list nobody acts on has bought none of the learning it paid for.

How the five events enact the three pillars

Each of the four events inside the Sprint inspects one thing and adapts another, and reading the pairs together shows that the framework has no inspection without a corresponding adaptation.

The Sprint is absent from the table because it adapts nothing. It is the container the other four run inside, which is why the length of a Sprint sets the slowest rate at which anything on the product can be inspected.

When the organisation hides bad news

If bad news is punished, what gets inspected stops being the work and becomes a version of the work that is safe to show. Progress is reported as on track, an Increment is called Done because saying otherwise is expensive, and impediments are described as under control. Transparency has gone at that point. The events then inspect a fiction, and every adaptation made from it rests on false information.

Nothing inside the framework detects this, because the artifacts still look right and the events still happen on time. That is why openness and courage are among the Scrum Values, and why the Scrum Master's work with the wider organisation is part of the accountability itself.

What the Scrum Master does for the three pillars

Each of the three pillars fails in its own way, and each of those failures is something the Scrum Master's accountability actually reaches. Transparency fails when an artifact stops saying what is true, so the work there is keeping the Definition of Done a real standard and saying plainly when an Increment nobody could release has not met it. Inspection fails when an event is dropped or cut short, so the work is ensuring every Scrum event takes place and stays inside its timebox. Adaptation fails when the team has no power to act on what it found, which is why the Scrum Master's service reaches into the organisation.

The inspections themselves belong elsewhere. The Developers inspect progress towards the Sprint Goal at the Daily Scrum, and the Scrum Team and its stakeholders inspect the Increment at the Sprint Review. When a Scrum Master reports progress for the team, reorders the Product Backlog after a review or picks the improvement the team will make next, an adaptation has arrived without the inspection that was meant to produce it.