When this question comes up, we laugh and quickly change the subject to David Hume, with whom we feel on firmer ground. But I’ve been reading Burke lately and may finally be able to answer this pressing question.
First some background. The Agile Manifesto spells out the principles of Agile design, which favours:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Agile is usually contrasted with the so-called “waterfall” method, whereby a plan is conceived by the bigwigs at the top of the org chart, then tumbles down to the folks on level two, who add their contribution before sending it down to the peons on level three, who pass it on to the schnooks on level four, and so on, until it arrives at the bottommost level, by which time the bigwigs have all been fired and their replacements have started work on an entirely different plan.
In an Agile environment, the bigwigs work alongside the peons on cross-functional teams that plan, design, and implement one or two small improvements at a time, in a series of short intervals called sprints, lasting a week or two. At the end of every sprint, a working piece of software is released, and the team pauses to consider the results and to set objectives for the following sprint.
Edmund Burke was a parliamentarian, pamphleteer, and the foremost English critic of the French Revolution. He’s sometimes smeared as a reactionary, but in fact he was a gradualist, who favoured measured change within a constitutional framework over all-encompassing plans dreamed up in a philosopher’s salon.
In Reflections on the Revolution in France he spells out the superiority of the gradualist approach:
[I]n my course I have known, and, according to my measure, have co-operated with great men; and I have never yet seen any plan which has not been mended by the observations of those who were much inferior in understanding to the person who took the lead in the business. By a slow but well-maintained progress, the effect of each step is watched; the good or ill success of the first, gives light to us in the second; and so, from light to light, we are conducted with safety through the whole series. We see, that the parts of the system do not clash. The evils latent in the most promising contrivances are provided for as they arise. One advantage is as little as possible sacrificed to another. We compensate, we reconcile, we balance…. From hence arises, not an excellence in simplicity, but one far superior, an excellence in composition.
Of course, by its very name, Agile would seem to be in conflict with the precepts of gradualism. The whole point of Agile is to allow for rapid adaptation to changing circumstances.
But that apparent conflict is an illusion, as Burke’s history teaches us. The French Revolution was the quintessential waterfall project, in which a small group of visionaries, untroubled by any practical concern for how governments and economies function, arbitrarily rewrote the entire body of their nation’s laws. Their plan, so elegant in the abstract, fell apart at its first collision with the reality of human behaviour. The inalienable Rights of Man gave way to factiousness, bloodshed, and tyranny. Almost a century passed before a stable French republic emerged.
In software terms, the French Revolution was a flashy new release that was so buggy and unpopular that it bankrupted the company.
Meanwhile the British, by an Agile process of small fixes and improvements, continued their “slow but well-maintained progress” toward universal democracy. Even now the Brits don’t have a written constitution, and they seem generally untroubled by the deficiency. You could say they favour “responding to change over following a plan”.
It might seem like a paradox, but Agile is a gradualist approach. Edmund Burke, it turns out, would approve.
Coming soon: Montaigne on Flash versus HTML5.