1.1 Scrum Theory & Empiricism

1.1 Scrum Theory & Empiricism

Official Scrum Guide Definition: Scrum is founded on empiricism and Lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.

To master the PSM I assessment, you must understand the philosophical engine that powers Scrum. Scrum is not a rigid plan or a set of step-by-step instructions; it is an empirical framework designed for managing work in complex, unpredictable domains.

---

Empirical Process Control vs. Defined Process Control

In traditional software development and traditional project management (often called "Waterfall"), organizations use Defined Process Control. Defined process control assumes that the problem domain is fully predictable, requirements can be completely known upfront, and a detailed plan can be executed sequentially without major deviations.

However, product development occurs in complex adaptive environments where requirements change, technology evolves, and unforeseen challenges arise. Attempting to use defined process control in a complex domain leads to massive budget overruns, missed deadlines, and poor quality product delivery.

Scrum replaces defined process control with Empirical Process Control (empiricism). Instead of making detailed long-term predictions, an empirical approach relies on frequent experimentation, short feedback loops, and real-time adaptation based on actual observed results.

The comparison table below highlights the fundamental differences between these two paradigms:

---

The Three Empirical Pillars

Empirical process control requires three pillars to function effectively: Transparency, Inspection, and Adaptation. These pillars form a continuous, interdependent loop. If any pillar is missing or compromised, empiricism fails and decision-making becomes flawed.

   ┌─────────────────────────────────────────────────────────┐
   │                       TRANSPARENCY                      │
   │  Work, artifacts, and processes must be visible to all  │
   └──────────────────────────┬──────────────────────────────┘
                              │ Enables
                              ▼
   ┌─────────────────────────────────────────────────────────┐
   │                        INSPECTION                       │
   │   Artifacts & progress toward goals frequently checked   │
   └──────────────────────────┬──────────────────────────────┘
                              │ Leads To
                              ▼
   ┌─────────────────────────────────────────────────────────┐
   │                        ADAPTATION                       │
   │   Adjustments made immediately to correct deviations    │
   └─────────────────────────────────────────────────────────┘

Pillar 1: Transparency

The emergent process and work must be visible to those performing the work as well as those receiving the work. In Scrum, important aspects of the process must be defined by a common standard so that observers share a common understanding of what is being seen.

• Examples of Transparency in Scrum:
  • A single, publicly accessible Product Backlog showing all planned work.
  • A shared Definition of Done ensuring everyone agrees on what "Done" means.
  • Open acknowledgment of team impediments, technical debt, and risks during Scrum events.
  • A transparent Sprint Backlog visible to the entire Scrum Team.

Exam Note: Without transparency, inspection is misleading and deceptive. If a team hides technical debt or incomplete work, stakeholders inspect a false reality.

Pillar 2: Inspection

The Scrum artifacts and progress toward agreed goals must be inspected frequently and diligently to detect undesirable variances or problems. However, inspection should not be so frequent that it gets in the way of work.

• Examples of Inspection in Scrum:
  • The Daily Scrum inspects progress toward the Sprint Goal.
  • The Sprint Review inspects the Increment and progress toward the Product Goal.
  • The Sprint Retrospective inspects team performance, interactions, tools, and processes.
  • Sprint Planning inspects the Product Backlog to select items for the upcoming Sprint.

Exam Note: Inspection is not an audit performed by external inspectors; it is an inspection performed by the Scrum Team itself to assess progress.

Pillar 3: Adaptation

If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

• Examples of Adaptation in Scrum:
  • Adapting the daily plan at the Daily Scrum when unexpected obstacles arise.
  • Adjusting the Product Backlog during or after the Sprint Review based on stakeholder feedback.
  • Implementing process improvements in the upcoming Sprint identified during the Sprint Retrospective.
  • Re-negotiating Sprint Backlog scope between the Product Owner and Developers during the Sprint.

Critical Exam Rule: Inspection without adaptation is pointlessly wasteful. Scrum events are specifically designed as formal opportunities for inspection and adaptation. If a team inspects issues during the Daily Scrum or Retrospective but takes no action to adapt, empiricism is broken.

---

Lean Thinking: Eliminating Waste

In addition to empiricism, the 2020 Scrum Guide explicitly states that Scrum is built on Lean thinking. Lean thinking emphasizes:

1. Focusing on Value: Delivering only what brings real value to the customer or product.
2. Eliminating Waste (Muda): Removing activities, features, documentation, or waiting times that do not add value.
3. Just-In-Time Planning: Deferring decisions to the last responsible moment when the most information is available.

In Scrum, Lean thinking is demonstrated by keeping artifacts lightweight, avoiding bloated upfront documentation, producing working Increments every Sprint, and keeping Scrum events tightly timeboxed.

---

Complex Adaptive Domains & The Cynefin Framework

Scrum is intentionally designed for complex problem domains. Understanding where Scrum applies helps answer theoretical questions on the exam:

• Clear / Simple Domain: Cause and effect are obvious. Best practice applies (Standard Operating Procedures work fine; Scrum is not needed).
• Complicated Domain: Cause and effect require analysis or expert knowledge. Good practices apply (predictive planning can work).
• Complex Domain (Scrum's Home): Cause and effect can only be perceived in hindsight. Requirements are unstable and emergent. Safe-to-fail experimentation and empirical feedback (Probe-Sense-Respond) are required.
• Chaotic Domain: No cause and effect relationship. Immediate action is needed to establish order.

Because software development, complex engineering, and modern product creation reside firmly in the Complex Domain, empiricism is the only effective way to navigate uncertainty.