Empiricism Is The Engine Under Every Framework

Strip the branding off Scrum, Kanban, XP, SAFe, LeSS and every methodology sold since, and what remains is the same three-step loop: make the real state of the work visible, look at it honestly at a known cadence, and change something as a result. Transparency, inspection, adaptation. Everything else — the roles, the events, the artefacts, the certification tracks — is scaffolding built to hold that loop in place inside an organisation that would otherwise not run it.

This matters because it tells you where to look when a framework "isn't working". The usual diagnosis is that the framework is wrong, and the usual remedy is to swap it for a different one, which produces a new vocabulary, a new training budget, and the same delivery performance. The more useful diagnosis is that the engine was never running. A sprint review where nothing real is demonstrated is not inspection. A dashboard that reports the plan rather than the work is not transparency. A retrospective whose actions require a decision nobody in the room can make is not adaptation.

Empiricism is not a philosophy about being open-minded. It is a control strategy with specific preconditions, and when those preconditions are absent it fails in predictable ways. What follows is why it exists, what each pillar actually demands, the conditions under which it breaks, and — the part most agile literature avoids — where you should be planning predictively instead.

Why empirical process control exists

The distinction comes from industrial process control, and it is worth stating in its original form because the software version is usually mangled.

A defined process is one where, given the same inputs and the same procedure, you get the same output within a tolerance you can specify in advance. Injection moulding is a defined process. Payroll is a defined process. For defined processes, the correct approach is to work out the procedure once, document it, and execute it. Planning in advance is not a compromise; it is the optimal strategy, and deviation genuinely is a defect.

An empirical process is one where the relationship between inputs and outputs is not well enough understood to specify in advance, or where variability is too high for a single specification to hold. For these, you build in frequent measurement and adjust as you go. You accept that the plan will be wrong and you buy the ability to find out quickly and cheaply.

Software development for novel business problems sits firmly in the second category, and the reason is not that developers are undisciplined. It is that the requirements are a hypothesis about human behaviour, the technical approach is a hypothesis about a system nobody has fully modelled, and the effort distribution for apparently similar items routinely spans an order of magnitude. Two stories that look identical at planning can differ by a factor of ten in reality, and no amount of estimation rigour removes that — it is a property of the work, not of the estimator.

The mistake is to conclude that all software work is empirical. A great deal of it is not, which is dealt with below.

The three pillars, stated precisely

The words are familiar to the point of being invisible. They are more demanding than they sound.

Transparency. Everyone involved sees the same state of the work, in the same terms, without translation. Not a summary of the state. Not a status the team was asked to assign. The actual state, including the parts that are inconvenient. Transparency is the precondition for the other two: you cannot usefully inspect a filtered view, and an adaptation based on a filtered view will be aimed at the wrong thing.

Inspection. Someone competent looks at the real artefact — running software, a live metric, an actual customer's behaviour — at a cadence frequent enough to matter, with enough skill to know what they are looking at. Inspection by people who cannot evaluate what they are seeing is a meeting, not a control mechanism.

Adaptation. Something changes as a result. Not "is noted as an action". Changes. This is where the loop most commonly breaks, and it usually breaks for structural reasons rather than motivational ones: the people doing the inspecting do not hold the authority to make the change the inspection implies.

Each pillar depends on the one before. Transparency without inspection is just an expensive information radiator. Inspection without adaptation is surveillance. Adaptation without transparency is thrashing.

Transparency is harder than dashboards

Most organisations believe they have transparency because they have tooling. Tooling produces the appearance of transparency at the cost of the substance, because every ticket state is a claim made by a human under social pressure, and in most environments there is a strong incentive for those claims to be optimistic.

The reliable test is whether bad news travels as fast as good news, and at the same volume. If a team discovers on Wednesday that the integration they depend on will not be ready, and that fact reaches the programme's decision-makers on Wednesday rather than at the next steering committee, you have transparency. If it surfaces in week eleven of a twelve-week plan, you have a reporting system that manufactures surprise.

Genuine transparency also requires that the increment being inspected is real. An increment demonstrated from a developer's machine, against seeded data, with the error paths disabled, is a performance. The definition of done exists to make transparency enforceable: it is the agreed standard for what "this is finished" means, so that the thing being inspected is the thing that would actually reach a customer.

Inspection without authority is surveillance

Here is the failure that hollows out more agile implementations than any other. A team inspects its own work honestly, identifies the constraint accurately, and finds that the constraint sits outside its boundary: a shared platform team's queue, an architecture review board, a release window controlled by a change advisory board, a funding decision made annually.

The team can see the problem clearly and can do nothing about it. Run that for two quarters and the inspection stops being honest, because honest inspection that produces no change is demoralising and people protect themselves from it. The retrospective becomes either a complaint ritual or a polite silence — a decay pattern examined in the retrospective problem.

The fix is not to exhort teams to be more open. It is to close the gap between where problems are seen and where they can be solved. That means either pushing authority down to the team, or committing a named person with that authority to act on what the inspection produces, on a stated timescale. Anything else is asking people to report faults into a void.

The feedback loop must be shorter than the decision cycle

This is the condition that decides whether empiricism works at all, and it is rarely stated explicitly.

Empirical control requires that you learn the result of a decision before you are forced to make the next one. If your release cadence is quarterly but your planning cadence is fortnightly, you are making six planning decisions per quarter on the basis of evidence from the previous quarter's release. You are not running an empirical process. You are running a predictive process with extra meetings, and the meetings will produce increasingly elaborate speculation because there is nothing else for them to work with.

The implication is uncomfortable for organisations that adopt ceremonies before fixing delivery: the cadence of your feedback is set by your slowest real loop, not by your calendar. If it takes eleven weeks for a change to reach a customer, your genuine inspection cadence is eleven weeks, whatever the sprint length says. Shortening that loop — smaller batches, fewer handoffs, automated verification, a shorter path to production — is therefore not an engineering nicety. It is the thing that makes every other agile practice function. This is why trunk-based development and batch size belong in a conversation about process, not just a conversation about tooling.

The four conditions under which empiricism fails

Condition	What it looks like	What to do
Feedback slower than the decision cycle	Fortnightly planning against quarterly releases	Shorten the delivery loop before adding ceremony
No real transparency	Status is assigned rather than observed; bad news arrives late	Inspect the artefact, not the report
Inspection without authority	Retro actions that require someone not in the room	Move the authority, or name the owner and a date
Cost of an experiment exceeds its information value	Safety-critical, irreversible or physically expensive changes	Plan predictively and model instead

That last row matters more than agile literature usually admits. Empiricism buys information by taking action and observing the result. When the action is cheap and reversible, that is an excellent trade. When the action is expensive, slow or irreversible — migrating a payment ledger, decommissioning a regulated system, a hardware production run — the information is not worth the price, and the correct response is rigorous up-front analysis, simulation, staged rollout and formal review. That is not a failure of agility. It is correct engineering judgement, and pretending otherwise is how the approach loses credibility with the people who control the riskiest work.

Complex, complicated, and where prediction is right

Cynefin gives the cleanest available vocabulary for this, and it is worth using precisely rather than as a slogan.

Clear work has an obvious, agreed answer. Apply the known practice. Do not convene a workshop.

Complicated work has a right answer, but it requires expertise to find. Analysis works. Prediction works. A database migration, a performance optimisation with a known bottleneck, an integration against a well-documented API — these are complicated, not complex, and treating them as though they require iterative discovery wastes expert time. If you have someone who has done this exact thing five times, let them plan it.

Complex work has no reliably knowable answer in advance; cause and effect are only clear in retrospect. New product features, changes to user behaviour, anything touching a market. Here you probe, sense and respond — small, safe-to-fail experiments rather than a big committed plan. This is the domain empiricism was built for.

Chaotic work requires action first and analysis second. Incidents. Stabilise, then understand.

The practical use is triage. Most portfolios contain a mix, and most organisations apply one governance model to all of it. Running predictive governance over complex work produces plans that are fiction. Running empirical governance over complicated work produces expensive rediscovery of things a senior engineer already knew. The competent answer is to sort the work and govern each category on its own terms — which is also the honest basis for the hybrid models most large organisations actually run, discussed in the honest comparison.

What to do on Monday

Measure your real feedback loop. Take the last ten changes that reached production and record, for each, the elapsed time from the decision to build it to the first observation of a customer using it. Take the eighty-fifth percentile. That number, not your sprint length, is the cadence at which your organisation is actually capable of learning.

Then compare it to your planning cadence. If planning is faster than learning, you have found the defect, and the remedy is on the delivery side rather than the process side.

Second, take your last three retrospectives and classify every action raised into three buckets: the team can do this alone; the team needs one named person outside it; the team needs a decision nobody in the building can make. If the second and third buckets dominate, your inspection is running into a wall, and the highest-value intervention available to you this week is to put someone with authority into the room — or to move the authority to the room.