Empiricism, Lean Thinking, and the Scrum Values

Introduction

This lesson belongs to the first focus area of the PSM I assessment, Understanding and Applying the Scrum Framework. Scrum.org does not publish a weighting per focus area, but the Scrum framework is by far the most heavily tested part of the assessment, and everything else you will learn (events, accountabilities, artifacts, Done) rests on the ideas in this lesson. If you understand why Scrum is built the way it is, a large share of exam questions become easy to answer, because the answer is the one that is consistent with empiricism, lean thinking and the Scrum Values.

The reference text is the Scrum Guide (November 2020) by Ken Schwaber and Jeff Sutherland, published under the CC BY-SA 4.0 licence at https://scrumguides.org/scrum-guide.html (opens in a new tab). The guide is short, and you should read it in full at least twice before sitting the assessment. This course quotes and paraphrases it with attribution.

After this lesson you will be able to define Scrum in the way the guide does, explain the three pillars of empiricism and the five Scrum Values, recognise lean thinking in Scrum's design, and judge whether a described behaviour supports or undermines transparency, inspection and adaptation.

Learning objectives

• State the Scrum Guide's definition of Scrum and its purpose.
• Explain empirical process control and why Scrum uses it instead of predictive planning.
• Describe transparency, inspection and adaptation and give a concrete example of each.
• Describe the five Scrum Values and how they show up in daily behaviour.
• Explain what lean thinking contributes to Scrum (reducing waste, focusing on the essentials).
• Recognise "Scrum-but" and other situations that break the framework's feedback loops.

1. What Scrum is, and what it is not

The Scrum Guide defines Scrum as a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems. Three words in that sentence matter for the exam.

• Lightweight. Scrum prescribes very little: three accountabilities, five events, three artifacts, and the commitments attached to them. It deliberately leaves out engineering practices, estimation techniques, tooling and document templates.
• Framework. Scrum is not a methodology and not a process with detailed steps. The guide says Scrum is purposefully incomplete, only defining the parts required to implement Scrum theory. Teams add their own practices inside the framework.
• Complex problems. Scrum targets work where requirements, technology and people interact in unpredictable ways. For simple, repetitive work a predictive plan is perfectly adequate; for complex work it is not.

The guide also states that 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. Scrum employs an iterative, incremental approach to optimize predictability and to control risk, and it engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed.

A final point from the opening of the guide: the parts of the framework are not optional. The guide says that while implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies and practices. This is the origin of the exam favourite "Scrum-but" ("we do Scrum, but we skip the Retrospective"). Skipping an event or an artifact removes a feedback loop, and the consequence is lost transparency or lost adaptation.

Example: a complex problem

A regional bank wants a mobile application that lets customers dispute card transactions. Nobody knows precisely which dispute categories customers will actually use, how the fraud-detection back end will respond under load, or how customers will react to a photo-upload step. A fixed 12-month plan would lock in guesses. Scrum lets the bank release a first Increment after four weeks that supports a single dispute category, observe real usage, and adapt the next four weeks accordingly. The complexity is the reason Scrum is appropriate.

2. Scrum theory: empiricism

Empirical process control is a process control approach in which decisions are based on observation, experience and experimentation. The guide names three pillars. All three are needed; each depends on the others.

Two details are frequently tested.

1. Transparency is about shared understanding, not just visibility. A burndown chart that nobody reads the same way, or a Definition of Done that Developers interpret differently, is not transparent. The guide says that low transparency decreases the value and increases risk. Inspection and adaptation built on opaque or misleading information lead to poor decisions.
2. Inspection without adaptation is useless, and adaptation without inspection is guessing. Scrum events are formal opportunities to inspect and adapt; the guide says they are designed to enable transparency. The guide adds that Scrum events are used to minimize the need for meetings not defined in Scrum.

Example: the three pillars on one team

A team building a ticketing platform notices in the Sprint Backlog that three items are tagged "almost done". The Definition of Done requires automated tests and a security scan, but two of the three have only manual tests.

• Transparency: the team makes the gap visible by showing the Definition of Done next to the board and by counting an item as done only if it fully meets it.
• Inspection: at the Daily Scrum, the Developers inspect progress toward the Sprint Goal and see that the real remaining work is larger than the board suggested.
• Adaptation: they swarm on the security scans, re-plan the rest of the Sprint Backlog and tell the Product Owner that one lower-priority item will not fit.

Notice that nobody waited for a manager or for the Retrospective. Adaptation happens "as soon as possible".

3. Why Scrum uses timeboxed iterations

Because inspection and adaptation need fresh information, Scrum organises work into Sprints of one month or less. The guide explains that a Sprint is the heartbeat of Scrum where ideas are turned into value, and that shorter Sprints can generate more learning cycles and limit risk of cost and effort to a smaller time frame. Details of the Sprint come in the lesson on events; for now remember the principle: the length of the feedback loop determines how quickly the team can learn, so Scrum keeps the loop short and fixed.

Scrum also uses an incremental approach: every Sprint can deliver one or more Increments that are usable and that together form the product. A practical consequence is that "we will test everything in a final hardening phase" contradicts Scrum, because an untested Increment is not inspectable.

4. Lean thinking

Lean thinking, which originates from lean manufacturing, focuses on delivering value and eliminating waste. In Scrum it appears in several places, even though the Scrum Guide does not use lean jargon heavily.

• Pull instead of push. Developers decide how many Product Backlog items they can select for the Sprint (they pull work). Nobody pushes extra work onto them mid-Sprint.
• Limiting work in progress. A Sprint Goal and a small number of items focus the team on finishing, not on starting.
• Eliminating waste. Features that nobody uses, handoffs between specialist groups, long waiting times for approvals and unfinished work are all forms of waste. The Product Backlog is ordered by value so that the team works on the most valuable things first, and the Increment must be Done so that no hidden "undone work" piles up.
• Continuous improvement. The Sprint Retrospective exists so the Scrum Team plans ways to increase quality and effectiveness each Sprint.
• Respect for people. Self-managing, cross-functional teams, rather than command and control, reflect the lean idea that the people doing the work know best how to improve it.

Comparison: predictive vs. empirical approaches

5. The Scrum Values

The Scrum Guide states that successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect and Courage. The Scrum Team members commit to achieving their goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems.

The values give direction with regard to work, actions and behaviour. The guide says that decisions that are made, steps taken and the way Scrum is used should reinforce these values, not diminish or undermine them. The Scrum Team members learn and explore the values as they work with the Scrum events and artifacts.

An exam tip: when a question asks which Scrum Value is demonstrated, look at the action described, not at the vocabulary. A Developer who announces at the Daily Scrum that an integration is much harder than expected is showing openness and courage; a team that says "we will not take on that extra story, so we can finish the Sprint Goal" is showing focus.

6. Worked example: choosing the empirical response

Scenario. A Scrum Team is in the third week of a four-week Sprint. The Sprint Goal is "Customers can pay with a saved card". At the Daily Scrum the Developers realise that the payment provider's sandbox is returning errors, so the forecast Sprint Backlog items cannot all be finished. The department head, who is not part of the Scrum Team, says that the team must commit to the original scope and work extra hours to show everything in the Sprint Review. What should the Scrum Team do?

Step 1: Identify what is at stake. The Sprint Goal is the single objective for the Sprint, and the Developers own the Sprint Backlog. The scope may be clarified and renegotiated with the Product Owner as more is learned, as long as the Sprint Goal is not endangered.

Step 2: Apply the pillars. Transparency: tell the Product Owner and the department head openly about the sandbox issue and its impact. Inspection: examine which Sprint Backlog items still serve the Sprint Goal. Adaptation: the Developers, with the Product Owner, renegotiate the scope. For example, they could drop the "remove a saved card" item while keeping the key payment path.

Step 3: Apply the values. Openness (say it now, not at the Sprint Review), courage (decline the unsustainable extra-hours demand), and focus (protect the Sprint Goal).

Step 4: Decide. The Developers adjust the Sprint Backlog, the Product Owner re-orders the Product Backlog for the next Sprint, and the Scrum Master helps the organisation understand why the team does not simply work longer hours.

Why the other options are weaker. Silently working overtime hides the real velocity of the team (a transparency problem) and produces unsustainable pace. Cancelling the Sprint is overkill because the Sprint Goal is still achievable; only the Product Owner has the authority to cancel a Sprint, and only when the Sprint Goal becomes obsolete. Letting the department head re-plan the work violates the self-management of the Developers.

7. Common pitfalls and exam tips

• "Scrum is a process with steps." The guide calls it a framework. If an option says "Scrum prescribes how Developers must implement features", it is wrong.
• "Empiricism means no planning." Scrum has Sprint Planning, a Product Backlog and a Product Goal. Empiricism means plans are adapted with evidence.
• Confusing the pillars. The Daily Scrum is mainly inspection of progress toward the Sprint Goal with adaptation of the Sprint Backlog; a status report to management is not its purpose.
• Treating the Scrum Values as posters. Exam questions describe behaviours; choose the answer that reinforces the values.
• Partial Scrum. If you read "the team drops the Retrospective because it is time-consuming", the right answer addresses the lost opportunity to adapt, not an alternative meeting.
• Wording traps. Words such as "must", "only" and "always" in options deserve careful reading. The Scrum Guide is explicit about what is required (for example, the Sprint length of one month or less) and silent about many things (for example, estimation technique).
• The Scrum Master is not a project manager. Empiricism requires the people who do the work to decide; this is developed in the lessons on accountabilities and self-management.

Exam tip. When two answers both seem plausible, choose the one that increases transparency, shortens the feedback loop, or lets the Scrum Team adapt earlier.

8. Mini case study

Context. Northwind Logistics has a Scrum Team of seven Developers, a Product Owner and a Scrum Master building a fleet-tracking dashboard. Over three Sprints the Sprint Review has been attended only by the Product Owner. Stakeholders say they are "too busy" and prefer a monthly email. The Developers have started marking items as done when the code is merged, although the Definition of Done also includes performance tests that rarely run. Last week a customer reported that the dashboard freezes for fleets above 500 vehicles. The Retrospective was skipped twice because "the release was urgent". The Product Owner reports to management that velocity is stable.

Question. Identify which parts of empiricism and which Scrum Values are being weakened, and propose actions.

Commented solution.

• Transparency is weakened. "Done" means different things for different people: the board says Done, the Definition of Done says otherwise. A velocity figure built on items that are not really Done is misleading. Action: only count an item as Done when it meets the whole Definition of Done; make undone work visible, for example by adding it back to the Product Backlog.
• Inspection is weakened. Stakeholders no longer inspect the Increment, so market feedback is missing; the performance problem was found by a customer instead of at the Sprint Review. Action: the Product Owner and Scrum Master invite stakeholders to a hands-on Sprint Review and show the working Increment, not slides.
• Adaptation is weakened. Skipping the Retrospective removes the formal opportunity to change the way of working. Action: reinstate the Retrospective and use it first to address the Definition of Done and the late performance testing, for example by automating performance tests in the pipeline.
• Values. Openness (the team and the Product Owner hide the true state of work), courage (nobody challenges the "urgent release"), commitment (the Definition of Done is not honoured) and respect (stakeholders disregard the team's request for feedback).

The Scrum Master's role here is to coach, to help the organisation understand empiricism, and to remove the impediment of stakeholders' absence, but the Developers are the ones who must honour the Definition of Done.

Key terms

• Scrum: a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
• Empiricism: knowledge comes from experience; decisions are based on what is observed.
• Transparency: significant aspects of the process and work are visible and commonly understood.
• Inspection: frequent, diligent checking of artifacts and progress toward goals.
• Adaptation: adjusting the process or the product as soon as possible when deviations appear.
• Lean thinking: reducing waste and focusing on the essentials.
• Sprint: a fixed-length event of one month or less; the container of all other events.
• Increment: a concrete stepping stone toward the Product Goal.
• Scrum Values: Commitment, Focus, Openness, Respect and Courage.
• Scrum-but: using only part of Scrum while still calling it Scrum.

Summary checklist

• I can recite the Scrum Guide's definition of Scrum and explain "lightweight", "framework" and "complex problems".
• I can explain that Scrum is founded on empiricism and lean thinking.
• I can define transparency, inspection and adaptation and match each to Scrum events and artifacts.
• I know that the Sprint is one month or less to keep feedback loops short.
• I can describe the five Scrum Values and recognise them (or their absence) in a scenario.
• I understand that Scrum is only Scrum when implemented in its entirety.
• I can resolve a scenario by choosing the answer that increases transparency and enables earlier adaptation.

Sources

• The Scrum Guide (November 2020), Ken Schwaber and Jeff Sutherland, CC BY-SA 4.0: https://scrumguides.org/scrum-guide.html (opens in a new tab)
• Scrum.org, Professional Scrum Master I assessment: https://www.scrum.org/assessments/professional-scrum-master-i-certification (opens in a new tab)
• Scrum.org, suggested reading for the Professional Scrum Master: https://www.scrum.org/resources/suggested-reading-professional-scrum-master (opens in a new tab)