Divide et Impera ■ Episode 01
Divide and conquer. The oldest strategy of control. Fragment the opposition. Isolate the units. Make them dependent on coordination from above.
Rather effective, as the Romans discovered some twenty-three centuries ago. It is happening in your engineering department right now. They call it "Agile."
The Manifesto
In February 2001, seventeen software developers gathered at a ski lodge in Snowbird, Utah, and wrote a manifesto. Four values. Twelve principles. The language was deliberately humanist: individuals and interactions over processes and tools. Working software over comprehensive documentation. Responding to change over following a plan.
These were not radical propositions. They were, in fact, so self-evidently sensible that one might wonder why they needed writing down at all. The answer, of course, is that the industry had spent the preceding decade doing precisely the opposite: burying developers under process documentation thick enough to stop a door, then acting surprised when the software arrived late and broken.
The manifesto was a corrective. A reminder that the people writing the code might, on occasion, know something about writing code.
It lasted approximately four years before the management consultants arrived.
The Takeover
What happened next deserves a diagram, because the sheer velocity of the drift from idealism to industrialisation is rather difficult to convey in prose alone.
The Scrum Alliance was founded in 2005. Within a decade, it had certified over one million Scrum Masters, a professional title that did not exist before the manifesto's ink had dried, and whose primary qualification is a two-day course and a fee. By 2014, one of the manifesto's original signatories was already writing the eulogy.
The Vocabulary Trick
The genius of the takeover, and it is a kind of genius, however dispiriting, lies in the vocabulary. Scrum did not reject the manifesto. It adopted the manifesto's language wholesale and quietly reassigned every word.
Daily standup was meant to be a brief, voluntary synchronisation amongst peers. It became a mandatory status report to management, held at a fixed time, with an implied obligation to justify yesterday's existence. Sprint review was meant to be a collaborative demonstration of working software. It became a performance evaluation with a Jira filter. Story points were explicitly designed to be relative estimates, deliberately abstract, unsuitable for cross-team comparison. They became productivity metrics. Naturally.
The words remained. The meaning inverted.
"But we're Agile!" No. You are doing Taylorism in a hoodie.
The Genealogy
Frederick Winslow Taylor published The Principles of Scientific Management in 1911. His central thesis was admirably straightforward: break work into the smallest measurable units, time each unit, optimise the worker. The factory floor as a machine. The human as a component.
Scrum, a century later, breaks work into story points, times each sprint, and optimises the velocity. The vocabulary has changed. The spreadsheet has moved to the cloud. The ideology has not.
Taylor at least had the decency to be honest about what he was doing. He called it "scientific management," which is neither particularly scientific nor especially manageable, but at least it does not pretend to be a philosophy of human empowerment. Scrum, by contrast, wraps identical assumptions in the language of autonomy and collaboration, which requires a rather more impressive suspension of disbelief.
The Feature as Casualty
Consider what happens to an actual feature under this regime. A piece of functionality that a single developer could design, build, and ship in a week gets sliced into twelve tickets across four teams. Each ticket must be estimated, refined, prioritised, and assigned. Nobody owns the whole thing. Integration is someone else's problem, or, more precisely, everyone's problem, which in organisational practice means nobody's.
You spend more time in refinement meetings than writing code. You try a better keyboard. A faster IDE. But none of that matters, because the bottleneck was never your typing speed. The point was never your productivity. The point is that you are measurable. Controllable. Trackable on a dashboard that someone three levels above you checks every Monday morning.
You wanted to build software. Instead, you move tickets.
The Certification Economy
This is the part where the economics become instructive, because the corruption of Agile is not merely philosophical. It is commercial.
An entire industry now exists whose revenue depends on Agile remaining complicated enough to require professional guidance. Certification bodies, transformation consultancies, conference circuits, tooling vendors, each with a vested interest in the proposition that "doing Agile properly" requires expertise that can only be purchased. The manifesto fits on a single page. The industry it accidentally spawned employs hundreds of thousands.
Martin Fowler coined a useful term for this: Faux Agile. The appearance of agility without the substance. Process compliance marketed as cultural transformation. A cargo cult with excellent branding.
The Inventors Speak
One might dismiss this analysis as the grumbling of someone who simply dislikes meetings. Fair enough. But the people who wrote the manifesto are saying the same thing, which rather complicates the dismissal.
Dave Thomas, manifesto signatory, 2014: "Agile is dead." Not the values. The values were always sound. The word itself. The brand. The industry that colonised it.
Ron Jeffries, co-creator of Extreme Programming and manifesto signatory, 2018: "Developers should abandon Agile." His reasoning is worth reading in full, but the summary is brisk: the practices that help developers were captured by processes that help managers, and the developers lost.
The people who invented it are telling you it has been corrupted. But do carry on.
The Uncomfortable Parallel
There is a pattern here that extends beyond software methodology, and it is worth naming plainly. Divide et impera, divide and rule, works by fragmenting a coherent group into isolated units that cannot coordinate without permission from above.
Scrum fragments a development team's autonomy into two-week increments that must be approved, estimated, and reported upon. It replaces trust with ceremony. It replaces judgement with metrics. It replaces ownership with ticketing. The developer who once understood a feature from requirements to deployment now understands a ticket from "In Progress" to "Done."
The scope of individual agency shrinks. The surface area of management oversight grows. This is not a side effect. It is the mechanism.
What Remains
The manifesto's values have not expired. They were correct in 2001 and they are correct now. Individuals and interactions over processes and tools remains excellent advice. Advice that is systematically ignored by every Scrum implementation that mandates a daily standup, a sprint review, a retrospective, a backlog grooming session, and a PI planning event, all administered through Jira, which is itself a process tool of such baroque complexity that it requires its own administrator.
The manifesto asked for less process. The industry responded with more process, rebranded as "Agile process," which is rather like responding to a request for silence by playing the quiet bits of Wagner.
The remedy is not another framework. It is not SAFe, or LeSS, or Nexus, or Disciplined Agile, or whatever the next acronym happens to be. The remedy is what the manifesto said in the first place: trust competent people, give them a problem, get out of the way.
Seventeen developers understood that in 2001. A million Scrum Masters later, the message appears to have been lost in translation.