Agile reads minds it cannot see

The joke at the origin

What the industry calls Scrum is close to the opposite of what its supposed inventors were after. In 1986 Hirotaka Takeuchi and Ikujiro Nonaka published “The New New Product Development Game” in the Harvard Business Review. It was not about software. It studied hardware firms — Honda, Canon, Fuji-Xerox, 3M, HP — and argued for a “holistic or ‘rugby’ approach” carried out by a hand-picked, multidisciplinary team: marketing, R&D, and production engineering all inside one group, moving the ball together. That is where the scrum comes from.

In most software companies today, Scrum is reserved for engineers and designers. Marketing, sales, and account management are held at arm’s length and given a name — stakeholders — so that everyone remembers they are outside the team. The 2020 Scrum Guide makes it official: the Scrum Team is one Scrum Master, one Product Owner, and Developers, and everyone else must influence the work by lobbying the Product Owner. Takeuchi and Nonaka wanted to dissolve the walls between functions. Scrum rebuilt them and put a fence around the coders. That is the surface irony. The deeper problem survives even a faithful implementation.

A small lens: you, tools, world

Take any activity to be some interaction with three things: yourself, your tools, or the world around you. One rule matters here — this lens can only be applied to yourself. No one has any epistemic privilege over anyone else. You do not know what another person thinks, feels, wants, or values, not really and not ever; the moment you design around someone else’s “needs,” you are guessing. A second consequence follows: there are no teams, only individuals. A team is not a thing that thinks or decides. It is a name for a lot of separate people doing separate work.

Almost every cognitive problem in Agile is a place where the method pretends to read another mind, or pretends a team is a person. Agile is obsessed with the world — shipped software, the customer, the market outcome — and fabricates the rest. It asserts things about the individual mind it cannot see, and it treats tools, including the human body, as machines that can hold maximum output forever.

The value problem

The first principle of the manifesto reads: satisfy the customer through early and continuous delivery of valuable software. The load-bearing word is valuable. You cannot judge what is valuable for someone else, because you cannot get inside them; and even when they tell you, they can be wrong, with no way to check. “Valuable” software usually means software a company can sell to its customers — people further away still. It is two layers of mind-reading, stacked and sold as a highest priority.

The industry eventually admitted as much. Product work stopped talking about value and started talking about hypotheses and pivots. Eric Ries gave it the liturgy: build, measure, learn; pivot or persevere; start from leap-of-faith assumptions and test them with a minimum viable product. This is candid — it concedes that no one knows what is valuable, so you ship something and watch. The word “valuable” was doing no work; the actual method is guess and check.

Notice what that does to the person building. In the craft world, shipping meant “I made something good and finished.” In the hypothesis world it means “we ran an experiment on the market, using four months of a life as the reagent” — and when the result comes back negative, someone says it wasn’t what they wanted, let’s redo it. There are only two ways out of that hole: decide the customer is a fool, or decide the work is meaningless. Either way the highest priority quietly inverts into spending as little of yourself as possible on software you already suspect will be thrown away. The same trap sits inside working software is the primary measure of progress. For a social product, “working” ought to mean two strangers having one real argument. To a room of engineers it means registration, a feed, and a deploy pipeline — because the people who could widen the definition were left outside the fence.

The people problem

Business people and developers must work together daily. Developer is a job title; business person is almost a slur. Read plainly, the principle admits it has no idea who these other people are or what they do all day, except that money is involved — so it calls them the money people. Takeuchi and Nonaka wanted cross-pollination, which in this lens is just curiosity: the only bridge across a wall you cannot see through. In practice, separate ceremonies, metrics, and rooms — with a Product Owner sitting in the gap like a customs officer — manufacture the opposite. Each side learns to see the other as an obstacle, and the result gets blamed on personality.

Build projects around motivated individuals. To do that, someone must first decide who is motivated, and before that, what motivation is — both moves that require seeing inside other people. The best-supported psychology says the assumption is empty: in Deci and Ryan’s self-determination theory, motivation is not a trait a person has but something the environment continually supports or thwarts through autonomy, competence, and relatedness. It is a weather system, not a badge. When reality failed to match the slogan, the industry invented a new word, self-motivated — a hoped-for trait that tops itself up forever, no matter what is done to it. Motivation is made and unmade between people; outsourcing it to a wished-for trait is how a team is surprised, every time, when it runs out.

And the most efficient method of conveying information is face-to-face conversation. Who decided that talking moves information best? It leans on memory, requires everyone free at the same instant, and vanishes when it ends. The research is not tidy. Prashant Bordia’s synthesis of the experimental comparisons found trade-offs, not a winner: text discussions run slower but produce more ideas and more equal participation, while face-to-face aids comprehension; in distributed teams, more asynchronous communication has predicted higher quality. Worse, the biggest reported barrier to a developer’s flow is interruption. “Get everyone in a room” and “protect deep, uninterrupted work” are in direct tension, and the manifesto endorses only one.

The phantom team

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior. Unpack the little machine in that sentence. A dozen people, in a short meeting, unanimously diagnose a complex problem, and each then changes behaviour accordingly — in a room with no peer pressure, no grudge, no concealed shame, no unnamed hierarchy, no shyness or dread or plain indifference, and with everyone agreeing on what “effective” means. There is no such creature. There is only Josh, and Priyanka, and six other people, each doing private arithmetic about what is safe to say.

The gentler research agrees. Rashina Hoda’s grounded-theory work on self-organizing Scrum teams finds the method leans hard on self-organization while giving almost no guidance on how it is meant to happen, and that real self-organizing teams are “not leaderless” — they are a constant balancing act between freedom and responsibility. Self-government, in the strict sense, is one of the hardest things people attempt: hard for nations, hard for two people sharing a kitchen. The best architectures, requirements, and designs emerge from self-organizing teams asks a dozen colleagues to do it every two weeks, on a deadline, and to produce excellent architecture as a byproduct — with no square on the board for a dead week, a bad month, or a mind that is elsewhere.

A constant pace, indefinitely

The sponsors, developers, and users should be able to maintain a constant pace indefinitely. It is one of the most inhuman sentences ever written into a professional document, and it seems to have survived because everyone quietly ignores it. It is a claim about tools — and the body is a tool — and about the mind: that both can hold maximum output, flat, forever. Nothing in physiology or psychology supports “indefinitely.” A life redistributes its energy constantly; ideation, grief, rest, a fallow month, a burst of obsessive focus are different allocations, not deviations from a norm. This is the sentence that the whole later discourse of work-life balance grew up to bandage.

It matters most for the one thing that makes work feel like one’s own. Technical excellence and good design — the only place the word agility appears in the manifesto, undefined — are where pride and meaning come from, and they come mostly from ideation, not implementation. Joseph Beuys built a philosophy on the line Denken ist Plastik: thinking is sculpture, the forming of an idea is the real creative act. A system that measures progress by shipping, treats output as the sole gauge of value, and demands a constant pace has nowhere to put the fallow, thinking-heavy week where the ideas actually form.

Twenty years later

The sharpest verdicts came from inside the movement, which is the part people forget. Martin Fowler, a manifesto signatory, calls most of what shipped “faux-agile” and rails against the “Agile Industrial Complex”; his older note on “Flaccid Scrum” had already named the mechanism — teams adopt the rituals, neglect the actual engineering, and end up with a mess, proof that the misery comes from ritual without capability, not from too little process. Ron Jeffries, another signatory, wrote that developers should abandon “Agile” and coined “Dark Scrum” for the way ordinary organizations turn the ceremonies into surveillance and pressure. Dave Thomas declared “Agile is Dead.” When the founders are the fiercest critics, “you’re just doing it wrong” stops being a satisfying explanation. Meanwhile the vocabulary quietly patched itself: customer became stakeholders, which installs the Product Owner as a filter between the people building and the people wanting, and work-life balance arrived as scar tissue over the one sentence nobody could live by.