Philosophy is sadly not my forté. A quick glance at the Wikipedia page on empiricism makes me instantly confuzzled. And yet it is quite important (at least for me as a Scrum Master) to have knowledge of this philosophical movement. The Scrum pillars of empiricism (transparency, inspection and adaptation) form the basis of the Scrum framework. So it might come handy to be able to explain in simple words what empiricism actually is. From a true philosophy noob, here’s my attempt at empiricism for dummies.
You were not born knowing anything (and neither was your roadmap)
Empiricism is the philosophical position that all knowledge comes from experience. Not from first principles, not from revelation, not from a well-formatted spreadsheet sent by leadership. Experience. The word traces back to the Greek ’empeiria’, through the Latin ‘experientia’, giving us ‘experiment’ and ‘experience’ in modern usage. The idea is as unglamorous as it sounds: you do not know something until you have encountered it.
The philosopher most associated with this view is John Locke, a 17th century British thinker deeply suspicious of claims to innate knowledge. Locke’s contribution was straightforward: the mind begins as a blank slate, a tabula rasa. It receives simple impressions from the five senses (a chair, a sound, a cold surface), and through reflection constructs more complex ideas. Nothing is pre-loaded. You have to live your way into understanding.
This is the reason science depends on observation and experiment rather than armchair theorising. In both natural and social sciences, a hypothesis only means something once tested against reality. Speculation is not knowledge. Evidence is.
That sounds obvious. Most people would nod along. And yet entire organisations build twelve-month roadmaps that treat tomorrow like a solved problem.
Why Scrum without empiricism is just a meeting schedule
Scrum is founded on empiricism. The Scrum Guide states explicitly that “Scrum is founded on empiricism and lean thinking.” The three pillars are defined as pillars of empirical process control, embedded across all five Scrum events. The 2020 revision strengthened this framing, making clear that empiricism is the epistemological foundation of Scrum, not an optional feature or a decorative philosophy section at the top of the document.
The three pillars (transparency, inspection, adaptation) are the mechanism by which an empirical process actually functions. Transparency makes the work visible so it can be inspected honestly. Inspection examines what the work reveals, including the uncomfortable parts. Adaptation means changing course when what you learned demands it. Remove any one leg and the structure collapses.
The Scrum Guide is clear on all of this. What it does not do is tell you how to maintain an empirical mindset, how to actually inhabit this way of working rather than just describe it in Sprint Reviews. That is the harder part. Three conceptions help.
The plan is the most expensive fiction in the room
There is a temptation, and it is seductive, to work out the final solution in advance. The full architecture, the complete user journey, the phased delivery roadmap with quarterly milestones. It feels like rigour. It feels like you are doing your job. It is, in most cases, an elaborate way of pretending you already know things you do not yet know.
The empiricist position is not that planning is worthless. It is that detailed upfront planning treats the future as though it behaves like the past, which it rarely does. Reality is more unruly. Requirements shift. Dependencies turn out to be more complicated than the slide deck suggested. The person who was absolutely certain in January is, by April, asking for something entirely different. (This is not a failure of process. It is just how complex work unfolds.)
Transparency, inspection, and adaptation exist precisely to handle this. Inviting stakeholders and experts into the process, regularly, not as a ceremonial end-event, is how you keep your observations grounded in what is actually happening rather than what you imagined would happen.
Changing your mind is not a failure: it’s the whole point
Scrum is built for unpredictable environments. Dave Snowden’s Cynefin framework (2007) positions most software development work in the Complex domain, where cause and effect are only coherent in retrospect. Snowden prescribes probe-sense-respond cycles in Complex contexts, as opposed to the sense-analyse-respond approach of the Complicated domain. This is the epistemological grounding for why an empirical process is not a stylistic preference in complex work but a structural necessity: predictive planning is the wrong tool for the domain. In Complex contexts, you cannot plan your way through the uncertainty. You can only probe, observe, and respond.
This means scope changes. It has to. Requirements shift as users interact with what you have built. Technology surfaces possibilities you had not anticipated. Stakeholders learn what they actually want by seeing what they said they wanted. Progressive insight, the thing that makes good Scrum teams visibly smarter over time, is not a management problem to be contained. It is the mechanism itself.
What gets in the way is an organisational assumption that changing requirements signals poor planning. “Scope creep,” they call it. But scope change is usually just information arriving in the order information arrives: late, messier than expected, and more useful than what came before. Adaptation is only a weakness if you believed the original plan was somehow sacred.
Someone else’s best practice is their lesson, not yours
Every Scrum Master eventually encounters the confident advisor who says: here is how you run retrospectives. Here is the sprint length that always works. Here is the velocity metric that will tell you everything you need to know. The advice arrives with authority and reasonable supporting evidence.
The empiricist response is not to dismiss it. It is to test it. Cynefin (Snowden) distinguishes between best practices, which apply in Clear contexts where cause and effect are predictable and repeatable, and emergent practices, which are discovered through safe-to-fail experimentation in Complex contexts. Scrum’s deliberate incompleteness as a framework is a direct application of this distinction: it refuses to prescribe solutions because the right solution depends on a context it cannot know in advance. Calling any Scrum practice universally “best” is itself an empiricist error.
Scrum is a lightweight framework, not a prescription. The Scrum Guide deliberately leaves significant space unfilled, not because the authors forgot to include instructions, but because the right way to work depends on your context, your team, your organisation, and the nature of the problem you are solving. What works brilliantly for a team in Amsterdam building a SaaS product may generate nothing but frustration for a team in Sydney maintaining legacy infrastructure.
Base your decisions on your observations. When someone hands you a practice and calls it universal, ask: universal under what conditions? Discovered by whom, in what context? What happened when they tried it somewhere different? No advice fits all. That is not a caveat. That is the epistemology.