Empiricism in Practice: Inspect and Adapt

Scrum is built on empiricism. Empiricism means working in a fact based, experience based, and evidence based manner. It asserts that knowledge comes from experience and making decisions based on what is observed. In Scrum, this translates to three pillars: transparency, inspection, and adaptation. Without transparency, inspection is misleading. Without inspection, adaptation is blind. This cycle is how Scrum Teams navigate complexity and deliver value effectively.

Transparency: The Foundation

Transparency ensures that the emergent process and the work are visible to those performing the work and those receiving the work. For example, a Product Backlog must be transparent to everyone. If items are unclear, or if their order is based on hidden agendas, the Scrum Team cannot inspect and adapt effectively. Similarly, the Definition of Done must be understood by all. If some team members think 'done' means code committed, but others think it means deployed to production, there is no transparency. This leads to false assumptions and poor decisions.

Inspection: Checking Progress and Conditions

Inspection involves checking progress toward a Sprint Goal to detect undesirable variances. It is not about micromanaging. It is about understanding the current state against the desired state. For instance, during the Daily Scrum, the Developers inspect their progress toward the Sprint Goal. They look at what was done yesterday, what will be done today, and if any obstacles exist. This inspection is frequent and focused. The Sprint Review is another key inspection point. Here, the Scrum Team and stakeholders inspect the Increment. They discuss what was accomplished in the Sprint and how market conditions or user needs may have changed.

Adaptation: Making Necessary Adjustments

Adaptation is the act of adjusting a process or product to minimize any deviations from acceptable limits. If an inspector determines that one or more aspects of a process deviate outside acceptable limits, the process or the material being processed must be adjusted. For example, if during the Daily Scrum, Developers realize they are unlikely to meet the Sprint Goal due to an unforeseen technical challenge, they adapt. They might re-negotiate the scope with the Product Owner or swarm on the problem as a team.

After inspecting the Increment at the Sprint Review, the Scrum Team and stakeholders adapt the Product Backlog. They might reorder items, add new ones, or remove old ones based on feedback and new insights. This ensures the Product Backlog always reflects the most valuable work to be done next.

The Sprint Retrospective: Formal Adaptation

The Sprint Retrospective is a formal opportunity to inspect and adapt the Scrum Team's process. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. They identify what went well, what problems they encountered, and what changes they can make. This leads to concrete improvements. For example, they might decide to:

• Improve their testing practices to reduce bugs.
• Adjust their Daily Scrum format to be more focused.
• Experiment with a new tool for collaboration.
• Refine their Definition of Done to include specific security checks.

These adaptations are added to the Sprint Backlog for the upcoming Sprint, ensuring continuous improvement of the team's way of working.

Empiricism in Action: A Cycle

Empiricism is not a one-time event. It is a continuous cycle of transparency, inspection, and adaptation embedded into every Scrum event. The Daily Scrum inspects daily progress and adapts the plan for the day. The Sprint Review inspects the Increment and adapts the Product Backlog. The Sprint Retrospective inspects the process and adapts the team's working agreements. This constant feedback loop is what allows Scrum Teams to deliver value in complex environments, where requirements and solutions evolve over time.

Start with the Foundations module →

Or take the full Scrum Master track →