A confrontation between craftsmanship and cargo cult.

Prelude

The scene: a whiteboard covered in sticky notes, each bearing cryptic abbreviations and story points. Two figures stand before it—one with the weathered patience of a builder, the other with the restless energy of one perpetually behind schedule. What follows is their exchange.

I. On Velocity and Value

The Architect: Another sprint concludes. Tell me, what has been built?

The Sprinter: We closed forty-seven story points. Velocity is up twelve percent from last quarter.

The Architect: I did not ask what was closed. I asked what was built. These are not the same question.

The Sprinter: The backlog shrinks. The burndown chart descends. These are the metrics of progress.

The Architect: A patient’s fever may descend while the disease advances. Metrics measure what is measurable, not necessarily what matters. Forty-seven story points of what? Features that cohere into a system, or fragments that accumulate into chaos?

The Sprinter: Each story delivers value to the customer. That is the Agile way.

The Architect: Value. You use this word as an incantation, as though its mere utterance transforms activity into achievement. But value to whom? The customer who receives a feature today that must be rewritten tomorrow? The developer who inherits code no one dared to design? The organization that mistakes motion for progress?

II. On Technical Debt and Temporal Theft

The Sprinter: Technical debt is acknowledged. We have a backlog item for refactoring.

The Architect: A backlog item. How reassuring. Tell me—in your experience, when does this item rise to the top of the prioritized list?

The Sprinter: When the debt becomes critical.

The Architect: Which is to say, when the house is already burning. You speak of debt as though it were merely financial—an obligation to be serviced at convenience. But technical debt is not owed to creditors who send polite reminders. It is owed to the future, and the future collects with compound interest.

The Sprinter: We cannot pause delivery to address every architectural concern. The business demands features.

The Architect: The business demands what it understands. It is your responsibility—our responsibility—to help it understand what it actually needs. When a patient demands morphine for a tumor, the physician does not simply comply. Diagnosis precedes prescription.

The Sprinter: You would have us stop and design for months before writing code?

The Architect: I would have you stop pretending that not designing is the same as being agile. The manifesto speaks of responding to change, not of abandoning forethought. It values working software, not merely deployed software. There is a difference between agility and thrashing.

III. On Iterations and Illusions

The Sprinter: Iteration is learning. Each sprint teaches us more about the system and the requirements.

The Architect: Does it? Or does each sprint merely reveal another consequence of decisions never consciously made? You speak of learning, but learning implies retention, accumulation, the building of understanding upon understanding. What I observe is closer to repetition—the same problems rediscovered, the same shortcuts retaken, the same debts reincurred.

The Sprinter: That is uncharitable.

The Architect: That is observation. How many times has this team “learned” that the database schema requires revision? How many sprints have included stories that exist solely to repair the damage of previous sprints? You iterate, yes—but toward what destination? A wheel also iterates. It covers the same ground endlessly.

The Sprinter: We cannot know the destination in advance. Requirements emerge.

The Architect: Requirements emerge, but architecture does not. Architecture must be cultivated, tended, defended against the entropy that every shortcut introduces. The cathedral builders of medieval Europe did not know every detail of their final structure, yet they understood arches and buttresses. They iterated within constraints that made iteration productive rather than merely perpetual.

IV. On Ceremonies and Substance

The Architect: Let us speak of your rituals. The daily standup—what purpose does it serve?

The Sprinter: Communication. Coordination. Identifying blockers.

The Architect: And does it accomplish these purposes, or has it become a performance? Fifteen minutes of status recitation, each participant waiting for their turn to speak rather than listening to comprehend?

The Sprinter: Some teams struggle with the format.

The Architect: Some teams? The format itself invites dysfunction. “What did you do yesterday, what will you do today, what blocks you”—these questions orient attention toward activity rather than outcome, toward the individual rather than the system. They are the questions of a supervisor, not a collaborator.

The Sprinter: The retrospective addresses systemic issues.

The Architect: Ah yes, the retrospective. Where the same observations are made sprint after sprint, documented on the same sticky notes, transferred to the same action items that somehow never reach the top of the backlog. The retrospective has become a ritual of catharsis—a space to voice frustration without the burden of resolution.

The Sprinter: You paint a bleak picture.

The Architect: I describe what I have witnessed across a dozen organizations, each convinced they were “doing Agile,” each producing the same patterns of dysfunction. The ceremonies persist because they are visible, measurable, auditable. The substance erodes because it is difficult, invisible, unrewarded.

V. On Design and Discipline

The Sprinter: What would you have us do differently?

The Architect: I would have you remember that Agile was a reaction against a specific pathology—the waterfall projects that spent years in analysis paralysis, producing specifications that were obsolete before implementation began. The cure was iteration, feedback, adaptation. But a cure taken in excess becomes a poison.

The Sprinter: You would return to waterfall?

The Architect: I would return to thinking. To the recognition that some decisions are expensive to reverse and therefore merit deliberation. That a database schema, once populated with production data, is not easily “refactored.” That an API, once published to external consumers, becomes a contract. That architecture is the art of identifying these irreversible decisions and making them consciously rather than accidentally.

The Sprinter: This sounds like Big Design Up Front, which Agile explicitly rejects.

The Architect: Agile rejects comprehensive documentation as the primary measure of progress. It does not reject comprehension. The manifesto values “the best architectures, requirements, and designs emerge from self-organizing teams”—emerge, not materialize from the void. Emergence requires conditions. Seeds emerge into plants only in suitable soil.

VI. On Craftsmanship and Cargo Cults

The Architect: Have you heard of the cargo cults of the Pacific islands?

The Sprinter: Vaguely.

The Architect: During the Second World War, island populations witnessed aircraft delivering valuable cargo. After the war ended, some islanders constructed mock airstrips, wooden control towers, and coconut headphones, believing these forms would summon the planes to return. They had observed the rituals without understanding the underlying system.

The Sprinter: You compare Agile practitioners to cargo cultists?

The Architect: I compare the degraded form of Agile—the sprint planning without architecture, the retrospectives without change, the velocity metrics without value measurement—to cargo cult practice. The forms are observed. The standups occur. The boards are updated. The ceremonies proceed. But the substance that made the original practices effective has been lost.

The Sprinter: That is harsh.

The Architect: That is diagnosis. The first step toward recovery is acknowledging the disease. Agile, as originally conceived, was a set of principles held by craftsmen who already understood their craft. They could iterate effectively because they had internalized the fundamentals. They could embrace change because they had built systems capable of accommodating change. The methodology assumed competence; it did not create it.

VII. On Recovery and Responsibility

The Sprinter: Then what hope is there?

The Architect: The hope lies in returning to first principles. Not the principles of the Agile Manifesto, but the older principles it presupposed—the principles of engineering, of craftsmanship, of professional responsibility.

The Sprinter: Which are?

The Architect: That we build systems to last, not merely to ship. That we take responsibility for the consequences of our decisions, including the decisions we failed to make consciously. That we measure our work not by velocity but by value, not by activity but by outcome. That we respect the future developers who will inherit our code, including our future selves.

The Sprinter: These principles are not incompatible with Agile.

The Architect: They are not. But they require something Agile alone cannot provide: judgment. The judgment to know when to iterate and when to deliberate. When to embrace change and when to defend a boundary. When to defer a decision and when to make it irreversibly. This judgment comes from experience, study, and reflection—not from certifications and ceremonies.

The Sprinter: (after a long pause) The sprint ends tomorrow. What would you have me do differently?

The Architect: Begin by asking a different question. Not “what can we ship?” but “what should we build?” Not “how fast can we move?” but “in what direction?” Not “what does the backlog contain?” but “what does the system require?”

The Sprinter: The product owner prioritizes the backlog.

The Architect: The product owner prioritizes features. You must prioritize foundations. These are different responsibilities, and conflating them is how we arrived at this impasse. The product owner is not equipped to judge architectural necessity; that judgment is yours to make and defend.

The Sprinter: And if the organization does not support this approach?

The Architect: Then you must decide whether you are a professional or merely an employee. The professional advocates for what is right, even at personal cost. The employee executes what is requested and disclaims responsibility for the consequences. Agile cannot make this choice for you. No methodology can.

Epilogue

The Sprinter stands before the whiteboard, its sticky notes suddenly appearing less like a plan and more like a prayer. The Architect has departed, leaving behind only questions that no retrospective will answer.

Somewhere, a sprint is ending. Somewhere, velocity is being celebrated. And somewhere, the foundations continue their slow, silent crumbling—accumulating the debt that the future will be forced to pay.

The Agile Delusion: A Dialogue on Software Craftsmanship

A confrontation between craftsmanship and cargo cult.

Achraf SOLTANI — January 21, 2026