1.2 Empirical Process Control

1.2 Empirical Process Control

Quick Answer: Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. The 3 pillars of Empirical Process Control are Transparency (making work and state visible), Inspection (frequently evaluating artifacts and progress), and Adaptation (adjusting process or product when deviations occur). Unlike defined process control, empiricism is required when work is complex and unpredictable.

At its absolute core, Scrum is not a methodology—it is an empirical process control framework. Every event, artifact, role, and rule in Scrum exists for one primary reason: to enable empirical decision-making in complex environments.

---

Defined Process Control vs. Empirical Process Control

To understand why Scrum uses empiricism, candidates must contrast it with Defined Process Control.

Defined Process Control (The Manufacturing Model)

Defined process control is designed for predictable, repeatable, and highly standardized operations—such as an automotive assembly line or chemical refining.

• Premise: The process can be fully defined, planned, and modeled upfront. If the inputs remain identical, the outputs will be identical every time.
• Response to Variance: When something goes wrong, defined process control assumes the workers failed to follow the prescribed step-by-step instructions. The solution is stricter compliance, tighter controls, and more detailed manuals.

Empirical Process Control (The Scrum Model)

Empirical process control is designed for complex, novel, and changing environments—such as software engineering, product innovation, and organizational change.

• Premise: The inputs are unpredictable, requirements change, and technology evolves. Perfect upfront planning is impossible because there are more "unknown unknowns" than knowns.
• Response to Variance: Knowledge comes from direct observation and real experimentation. Teams execute short loops of work, inspect the actual results, and adapt both the product and the process continuously.

---

Comparison Matrix: Defined vs. Empirical Control

---

The Three Pillars of Empiricism

Empirical process control cannot function if any of its three pillars is missing. On the CSM exam, scenario questions often present a situation where one pillar has collapsed, asking you to diagnose the failure.

           +---------------------------------+
           |   EMPIRICAL PROCESS CONTROL     |
           +---------------------------------+
           |  TRANSPARENCY                   |
           |    └── Shared understanding     |
           |  INSPECTION                     |
           |    └── Detecting variance       |
           |  ADAPTATION                     |
           |    └── Adjusting process/product|
           +---------------------------------+

Pillar 1: Transparency

Definition: Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires that aspects be defined by a common standard so observers share a common understanding of what is being seen.

• Key Exam Concepts:
  • Common Language: The team and stakeholders must share vocabulary. If a team says a feature is "Done," everyone must mean the exact same thing.
  • Definition of Done (DoD): The ultimate tool for transparency regarding Increment quality. Without a shared DoD, "Done" is an illusion.
  • Visible Artifacts: The Product Backlog, Sprint Backlog, and working Increment must be visible to all. Hiding impediments, fake status reports, or secret backlogs destroys transparency.

Pillar 2: Inspection

Definition: Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances or problems. However, inspection should not be so frequent that it gets in the way of the work.

• Key Exam Concepts:
  • Purposeful Inspection: Inspection is not an audit by external managers; it is an active evaluation by the Scrum Team itself.
  • Inspection Cadence: The 5 Scrum events provide mandatory formal inspection points (e.g., inspecting the Increment at Sprint Review, inspecting team collaboration at Retrospective, inspecting progress toward Sprint Goal at Daily Scrum).
  • Inspection Without Adaptation is Pointless: If a team inspects defects or delays but does nothing to fix them, inspection is wasted effort.

Pillar 3: Adaptation

Definition: If an inspection determines that one or more aspects of a process deviate outside acceptable limits, or that 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.

• Key Exam Concepts:
  • Timeliness: Adaptation must happen immediately when variance is discovered. Waiting weeks for a change-control board destroys empiricism.
  • Self-Management: The team adapts its own behavior, Sprint Backlog, and technical practices without waiting for external management permission.
  • Retrospective Action Items: The team selects at least one high-priority process improvement item during the Sprint Retrospective to implement in the upcoming Sprint.

---

How the Scrum Framework Implements Empiricism

Every structural component of Scrum directly supports one or more pillars of Empiricism:

---

Real-World CSM Scenario & Exam Failure Modes

Scenario: During a Sprint Review, a Product Owner presents a slide deck showing completed software features. When a key stakeholder asks to see the live software running in a test environment, the Product Owner replies: "The code is written, but QA hasn't tested it yet, and deployment scripts aren't ready. However, we considered it 90% done so we included it in our presentation."

Empirical Failure Diagnosis:

1. Breakdown of Transparency: The term "Done" was misrepresented. Presenting slides instead of a functional Increment creates false transparency.
2. Breakdown of Inspection: Stakeholders cannot inspect paper slides to assess real product utility, stability, or user interface flow.
3. Required CSM Action: The ScrumMaster must coach the Product Owner and Scrum Team that only fully completed Increments meeting the Definition of Done may be presented at Sprint Review. Items not meeting the DoD remain in the Product Backlog and cannot be counted toward Sprint progress.