What Has to Be True for Agile to Be Beneficial?

Last week’s essay closed with an invitation: this essay is itself a claim, you should apply the move to it. Before doing that, it seems worth applying it to something else first. Something where the stakes are higher than the method itself, where the claim has been repeated for long enough to acquire the texture of common knowledge, and where questioning it is socially expensive enough that the load-bearing assumptions are unlikely to have been examined recently.

Agile fits that description as well as anything I can think of. In software-intensive industries, the proposition that Agile is beneficial has reached the point where it is no longer defended; it is simply assumed. To question it is to mark oneself as either uninformed or behind the times, which is precisely the social signal that, in last week’s terms, indicates a claim whose conditions have stopped being checked.

The strongest version of the claim, the one an advocate would actually make, has a chain structure. The future is inherently uncertain. The ability to react to changing conditions is therefore valuable. Agile is the family of approaches that delivers that ability. Three propositions, chained together, each doing different work.

The neat thing, neat in the sense of being convenient rather than contrived, is that each link in the chain corresponds to a different one of last week’s three categories. The future is uncertain is an existence claim. Reactivity is beneficial is a mechanism claim. Agile delivers reactivity is an exclusivity claim. The structure of the assertion lines up with the structure of the analysis, which means the essay can take the three sub-claims in order and let the framework do its work.

What follows does not argue that Agile is wrong, and does not propose an alternative. It applies the move from last week to a target where the move actually changes what you can see.

obviously created by AI

Which Agile?

Before the analysis can begin, the claim has to be pinned down, because Agile is not one thing.

There is Agile as a stance: the disposition the original Manifesto authors named, oriented toward uncovering better ways of working through doing the work and helping others do it. Provisional, empirical, suspicious of fixed plans in domains where fixed plans cannot be honoured. There is Agile as a family of practices: Scrum, XP, Kanban, the various concrete methodologies that emerged around the stance. And there is Agile as an organisational programme: the certifications, the transformation initiatives, the consultancies, the industry that has accumulated around the term.

These three things are routinely treated as if they were the same thing. They are not. The strongest case for Agile is made on behalf of the first; the implementation that most organisations actually run is the third. That gap is a real assumption, and it is doing real work in defences of the claim. But it is not the assumption I want to examine in this essay.

The collapse runs in both directions, and not only in defences. The current claim that Agile is outdated because of agentic coding tooling, for example, almost universally treats Agile as synonymous with Scrum, Scrum as synonymous with the two-week sprint, and proceeds to argue against the resulting compound as if it were the stance itself. Whether the claim is being defended or attacked, the same conflation is doing the work, and the same examination has to come first.

For what follows, I am working with Agile-as-stance. This is a deliberate methodological choice, borrowed from last week: examine the claim in its strongest form, not the easiest form to dismiss. If the assumptions fail at the level of the stance, they fail everywhere downstream. If they hold at the level of the stance, then a separate question — what has to be true for specific practices and frameworks to deliver on the stance — becomes worth asking on its own terms. That is a follow-up essay, and a substantial one. It is not this one.

The object of analysis, then, is the proposition that adopting a provisional, empirical, learning-oriented disposition toward work in conditions of uncertainty is beneficial. That is the claim. The chain of three sub-claims is what the proposition rests on.

The existence assumption

The future is inherently uncertain.

This is the first link in the chain, and it is the strongest of the three. Most of the work this essay needs to do is downstream of it, but the claim deserves a fair examination on its own terms.

For substantial portions of knowledge work, especially software development in non-trivial domains, the claim holds. Requirements are emergent rather than discovered. User behaviour is learned through contact with actual users, not predicted from a specification. The interaction between components, between systems, between teams, produces effects that no upstream analysis fully anticipates. Treating these conditions as if they were merely complicated, as if a sufficiently rigorous plan could capture them, is the failure mode that Agile-as-stance was articulated against. To that extent, the existence assumption is well grounded, and the rest of this series has been making versions of the same case throughout.

But there is a boundary condition the claim quietly elides, and it matters.

Uncertainty is not a uniform property of work. Some work is uncertain in the way the stance assumes: requirements that emerge through use, technical risks that resolve only through implementation, user needs that practitioners cannot fully articulate in advance. Reactivity, in that domain, is genuinely the right response, because the relevant information arrives during the work and not before it.

Some work is uncertain in different ways. Regulatory changes, competitive moves, organisational restructuring, the political environment around a programme: these are sources of uncertainty that reactivity at the work level cannot meaningfully address. The information arrives, but it arrives in forms that local agility cannot convert into useful response. Treating this kind of uncertainty as if it were the kind the stance was designed for produces a particular sort of disappointment: the team is reactive, the system around it is not, and the gap is read as a failure of Agile rather than as a misapplication.

And some work is genuinely not uncertain in any meaningful sense. Well-understood, low-variability, repeatable. The argument that all knowledge work is fundamentally uncertain has been used to extend Agile into domains where the claim does not survive scrutiny. Not every situation that involves humans and judgement is structurally analogous to product development. Some work is closer to a manufacturing process than its practitioners would like to admit, and applying a stance designed for genuine uncertainty to work that does not have it is its own kind of category error.

The existence assumption holds, then, but conditionally. The claim that the future is uncertain is true of some domains, partially true of others, and not really true of a third group. Agile is beneficial applied universally requires the universal version of the assumption, which does not hold. Applied with awareness of the boundary, the assumption is defensible. The difficulty is that the universal application is the form the claim usually takes, and the boundary almost never gets named.

This is the cleanest of the three sections. The harder work is downstream.

The mechanism assumption

The ability to react to changing conditions is beneficial.

This is the mechanism assumption: the proposition that reactivity, when achievable, converts uncertainty into better outcomes. It is where the analysis gets sharper, and where the rest of this series carries most of the weight.

Even granting that the future is uncertain in the relevant sense, it does not automatically follow that reactivity produces benefit. The mechanism has to actually work, which means the conditions under which it works have to actually exist. They frequently do not, and the reasons connect directly to mechanisms the rest of the series has spent considerable time describing.

The first problem is that reactivity requires the capacity to react, and that capacity is precisely what the surrounding organisational system most reliably destroys.

In *Trained Not to See* I described how organisational formation produces a particular kind of epistemic narrowing in managers: a trained inability to engage with uncertainty as a structural property of complex systems, rather than as a problem to be solved through better planning. The stance Agile rests on requires exactly the disposition that formation removes. A manager who has been rewarded throughout a career for performing certainty, who has been filtered for fluency in the planning-and-control frame, who has internalised the equation between confidence and competence, is not a person well placed to hold a provisional, empirical, learning-oriented posture toward work. They might say they are. The system around them might require them to say so. But the underlying disposition has been selected against, generation after generation, by exactly the institution now claiming to embrace its opposite.

The second problem is that reactivity at the team level does not aggregate to reactivity at the system level — as issue I briefly touched in *The Wrong Level*. A team that adapts thoughtfully to its sprint feedback is operating inside a portfolio, an organisation, a market. If the surrounding system has already committed to fixed plans, allocated budgets against annual cycles, made promises to customers or boards or regulators that cannot now be revised, then local reactivity does not produce systemic reactivity. It produces a team that is responsive to signals it cannot act on. The team learns; the system does not absorb the learning; the gap accumulates as frustration, as quiet attrition, as the slow conversion of practitioners who once believed in the stance into practitioners who go through the motions of it.

The third problem is the one I described in *Chain of Pressure*. Reactivity requires cognitive space: time to read what is actually happening, think it through, decide on a response that is appropriate to the situation rather than reflexive. Pressure compresses that space. And pressure is not incidental to organisations; it is structural, and it transmits through hierarchies in ways that compound rather than dissipate. By the time a strategic mandate has reached the level where the actual work happens, it has often been converted into an urgent demand for execution, with the cognitive space for thoughtful response already eliminated several links upstream. A team operating under that kind of pressure cannot be reactive in the sense the stance requires. They can be responsive to instructions. They cannot be responsive to learning, because the conditions under which learning becomes actionable have been removed before the learning can occur.

The fourth problem, and the one most directly connected to last week’s essay, is identity. The stance requires holding one’s current understanding provisionally. Practitioners whose careers have formed around specific practices, frameworks, or methodologies have, over time, fused that knowledge with their professional identity in the way described in *Your Current Self May Be Impeding Your Future Self*. The provisionality the stance asks for becomes, for them, not a methodological commitment but an existential threat. They can advocate for the stance. They can teach it. What they cannot do, structurally, is apply it to the practices they have most invested in. The very disposition Agile depends on is the one most reliably extinguished by the careers that grow around it.

Each of these four problems is sufficient on its own to break the mechanism assumption. They occur not separately but together, in the same organisations, on the same teams, in the same individuals. The compounding is not accidental. They are different facets of the same structure: a system that produces practitioners and contexts in which the stance Agile depends on cannot actually be held.

The mechanism assumption, then, is not generally false. Reactivity, when achievable, is genuinely beneficial. The problem is that the conditions under which it is achievable are precisely the conditions that the surrounding system most reliably prevents. The claim Agile is beneficial assumes the mechanism works because it assumes the conditions for its working are present. They usually are not. And the absence is not a temporary failure to be corrected through better implementation; it is a property of the system the stance is being applied within.

This is the section where the connection to the rest of the series does the most work. None of the previous essays named Agile directly. All of them have been describing, in one form or another, the failure of the conditions Agile-as-stance depends on.

The exclusivity assumption

Therefore Agile is beneficial.

The third link is the exclusivity assumption, and it is the one most often skipped entirely. Even granting the existence assumption (uncertainty is real) and the mechanism assumption (reactivity, when achievable, helps), the claim still requires Agile to be the right expression of the stance among the available alternatives. This is a stronger claim than it appears, and the way it usually fails is more interesting than a simple comparison of alternatives would suggest.

Here I need to make a distinction that matters. Agile and Scrum are not synonyms, even though much of the industry treats them as if they were. Scrum is one implementation of the stance. There are others. Flow-based methods, for instance, are not an alternative to Agile; they are another implementation of the same stance, with a different emphasis: stable flow, short cycle times, just-in-time refinement, decision-making at the last responsible moment, the deliberate avoidance of premature commitment. Whether one implementation expresses the stance better than another is a question worth asking, but it is not the question I want to settle here. What matters for this section is that more than one implementation exists, and that the existence of alternatives is itself part of what the exclusivity assumption depends on.

This matters because it changes what the exclusivity question is actually about. The question stops being Agile vs. non-Agile and becomes which expression of the stance, selected on what grounds, in preference to which alternatives that were never seriously considered.

What was selected, by and large, was Scrum and its descendants. What it was selected over includes flow-based methods, along with a number of other approaches with their own claims on the stance, suited to different domains and different kinds of work. The selection happened. The grounds on which it happened are worth examining, because they bear directly on whether the exclusivity assumption holds.

Scrum’s dominance was not the outcome of a comparison of methods on the merits. It was the outcome of an industry: of certifications that produced revenue, of training pipelines that produced consultants, of frameworks that scaled into enterprise transformation programmes, of vendor relationships that locked in tooling and language. The chain-of-pressure dynamic from an earlier essay played its part here too. Organisations under pressure to demonstrate Agile capability needed something they could buy, certify, and roll out at scale. Flow-based methods, with their requirement for serious engagement with the actual flow of work and the actual sources of variability, did not package as cleanly. Scrum did. The selection happened on those grounds, and the grounds had little to do with how well the result delivered on the stance.

This is local optimisation, in the same sense the earlier essay used the term, but operating at the level of the industry rather than the team. Each actor in the system, locally rationally, selected the version of Agile that minimised their own friction: certification bodies that needed something certifiable, consultancies that needed something teachable, executives that needed something demonstrable. The aggregate outcome is an industry that has converged on a particular implementation, not because that implementation is the best expression of the stance, but because it is the one that most reduced the friction at every step of its own propagation.

What this does to the exclusivity assumption is precise. The claim Agile is beneficial, as it operates in practice, is doing the work of the dominant implementation of Agile is beneficial. The dominant implementation was selected on grounds that have no necessary relationship to how well it delivers the stance. Other implementations exist, with their own claims on the stance and their own evidence to consider, that were never given a serious comparative evaluation in most organisations because the industry’s selection mechanism filtered them out before the choice could be made.

The current debate about whether agentic coding tools have made Agile obsolete is, on examination, the same confusion running in the opposite direction. The critique lands cleanly on the iteration ceremonies, the meeting cadence, the two-week rhythm. It barely touches the stance. And the proposed alternative, larger specifications written upfront with the implementation phase compressed by AI, returns to a pre-Agile posture, with two of the assumptions the stance rests on now failing more thoroughly than before. The existence assumption fails first: uncertainty about what should be built is denied, on the assumption that a sufficiently detailed specification can be written in advance of the work that would reveal what it should contain. A mechanism assumption is added that is, if anything, more brittle than the one it is replacing: that the relevant implementation details are knowable before the implementation, and that the speed of execution is the bottleneck rather than the quality of the questions being asked. There is a quieter assumption beneath both, harder to spot because it presents itself as a corollary of the speed gain: that throwing away the wrong implementation and redoing it is a cheap operation, so the cost of being wrong about the spec is low. We do not yet know whether this holds. The token costs are not negligible; the embedded assumptions in a generated codebase are not always visible until they are inherited by the next iteration; and the cognitive cost of evaluating whether the regenerated version is genuinely better than the discarded one is borne by humans, who do not get faster as the AI does. None of this is yet settled. What is being treated as a given is in fact one of the more interesting open questions in the practice. The critics believe they are arguing against the stance. They are arguing against Scrum, and proposing as their alternative something that violates the stance more completely than what they are replacing.

A note on tone, before this section closes. The aim here is not to attack Scrum practitioners. They did not narrow the option space; the option space was narrowed for them, by the same chain-of-pressure dynamic that shapes most of what organisations end up adopting. Many of them are doing serious, thoughtful work within the implementation they were given. The point is that the implementation they were given was given on grounds the claim does not acknowledge, and the gap between this implementation is what we have and this implementation is what the stance requires is one the claim quietly closes without examining.

The exclusivity assumption fails, then, at a deeper level than the trivial observation that alternatives exist. It fails because the selection was never genuinely made on the relevant grounds. The choice that the claim assumes was made was, in most organisations, never actually a choice.

The recursion

The analysis above rests on its own assumptions.

The three categories themselves are a frame, inherited from last week, and they shape what gets surfaced as well as what doesn’t. The judgement that the mechanism assumption fails relies on evidence drawn from the rest of this series, which is itself a body of claims with its own load-bearing assumptions. The treatment of flow as another implementation of the stance is a position, not a neutral observation, and someone operating in a different frame might draw the boundaries elsewhere. A reader could go a layer deeper than this essay has gone and find the analysis resting on premises that would themselves require examination.

This is the condition last week’s essay described: every validator rests on assumptions, and the question is never whether you have reached certainty but how many layers deep you have looked.

What this analysis has done is go one or two layers further than the claim is usually examined. That is not the final word on Agile. It is enough to make the load-bearing structure visible, which is the actual purpose of the move. What a reader does with that visibility is theirs.

Not a verdict

The point of last week’s method is that assumption-analysis does not produce verdicts. It produces clarity about where the weight is resting.

What this analysis has produced is something less satisfying than a conclusion and, I think, more useful.

The existence assumption holds in some domains and not others, which means the universal version of the claim is too strong, and the question is the kind of uncertainty I am facing the kind Agile-as-stance was designed for is one each practitioner has to answer locally. The mechanism assumption depends on capacities that the surrounding organisational system frequently destroys, which means that even where the existence assumption holds, the conditions for the stance to deliver are usually absent in ways that cannot be corrected by adopting the stance harder. The exclusivity assumption depends on an option space that was, in most organisations, never genuinely surveyed, which means the question is what we are doing the best available expression of the stance is one most organisations have never actually asked.

None of this tells you whether Agile is beneficial. It tells you under what conditions it would be, and asks you to look honestly at whether those conditions hold where you are.

For practitioners whose identity has fused with the practice in the way previously described, the analysis is unlikely to land at all. The mechanism that essay described will route the question elsewhere before it can be examined.

For practitioners who hold the practice loosely enough to examine it, the question changes shape. It stops being is Agile good and becomes the more useful one: under what conditions, in what form, against what alternatives, would a provisional, empirical, learning-oriented stance toward this work actually deliver what the claim says it delivers, here, given what I now see about the system this work sits inside?

That is a question with answers. The original claim was not.

Supplement on 2026–05–09: The next piece in the series is published. It looks at Agile as a family of practices, using Scrum and Kanban as major representatives of said family, and applying the assumption analysis move at them.