Conspiracies can be fun. Based on just enough superficial evidence or correlation, they allow us to indulge our imaginations and let off some steam. But what happens if we stumble onto a hush-hush cover-up that we were never supposed to find? Is your system just slow today, or is there a key logger running? You better conceal that camera on your monitor (hey, it’s not being paranoid when everyone is out to get you!) We are about to explore some agile conspiracies, so get your cover-up ready...
1. Agile as a Means to Prevent Outsourcing
Outsourcing software development to smart people working for less money overseas loomed large over the IT industry in the 1990s as giants like IBM and Fujitsu opened mega data centers in India and China. Fortunately, a ragtag band of visionaries met in Snowbird, Utah to thwart the threat before it became a reality.
Understanding that detailed specifications and good plans allowed for work to be successfully handed off to third parties, they set about undoing these best practices. If they could successfully sabotage the building blocks of successful handoffs, then the outsourcing trend could be stopped--or at least slowed.
By insisting that customers did not know what they wanted (and couldn’t explain it anyway), they undermined years of progress in requirements specification and project planning. When challenged on these claims, they played their ace card by saying that since publishing their findings there had been no business groups complaining or refuting their findings--so they must be true (when in fact no one outside of the software world had any idea what agile was or that anything had been published). Yet without anyone to call “Foul!”, their message stuck and began to grow.
Some early adopters saw the end goal and jumped on the bandwagon, reinforcing the cause through their own findings; others blindly followed the new calling, thinking it made sense. Even the agile manifesto founders were amazed when the real benefits were not discussed at the first Agile Conference as more and more people joined the cause. Knowingly or unknowingly, the movement grew.
2. Agile as an Excuse to Avoid Documentation
By sitting together, scribbling on lots of white boards, making up silly names for things and setting up traffic lights and playing with poker cards - all diversions from having to do any documentation, agile methods pulled the classic switcheroo. Not only did they conveniently do away with documentation, but they introduced so many other questionable activities that the original question (“Where’s your documentation?”) got lost in the shuffle. It’s a bit like going into your teenager’s bedroom to tell them to clean it up--only to find they have a piercing and some questionable looking “vitamins” hidden away, your original concern about cleanliness soon forgotten.
The brilliance with agile’s take on decision making, estimation and planning is that, technically, some of the elements are still there -most people don’t know where to begin questioning it, so they just label it “agile” and leave it alone.
3. Agile for the Inattention Economy
Youngsters today entering the workforce have no powers of concentration, reading or writing skills. So Agile methods are the only way to usefully engage them. Conditioned by commercial breaks in TV programs every 15 minutes and brought up on comic strips rather than books, agile methods have cleverly reengineered the workplace for the cartoon generation.
Can’t get your Gen Y workers to stay focussed through a status meeting? No problem, try Daily Stand Ups instead, they are timeboxed to 15 minutes, that magic period of concentration on TV before a commercial break is necessary. Can’t get your texting teammates to string a few sentences together without inserting smiley faces and LOL emoticons? No problem, switch from specification documents that require paragraphs and sentences to User Stories that are more like Tweets than real requirements anyway.
Having problems getting twenty something’s to plan and make long term project commitments? One week iterations are your cure, just like episodes of Buffy, every week the cycle repeats and since 7 days matches the maximum planning horizon for your new team mates at last we can all be on the same page!
4. Agile as an Excuse to Ignore Architecture
The architects are that bunch of goody-two-shoes idealists who preach about open standards and best practices but never have to make “Sucky System ‘A’” talk to “Clunky System ‘B’” using “Awful Interface ‘C’”. Architects typically drop in, make some over-simplified generalizations, ignore the constraints and practicalities of what really happens and then clear off before the faults in their recommendations can be proven beyond doubt.
You can argue with them, but it is more fun and rewarding to just nod and then ignore them. Of course, to get your project approved you have to be reviewed and agree to follow architectural standards. But not to worry since agile has the secret weapon called “refactoring”, which basically gives the team the right to go and change the architecture whenever they like (in fact, refactoring often is encouraged as it “enhances agility”).
A bit like having diplomatic license plates on your car, you are still technically governed by the traffic laws of the host nation, but you can ignore any tickets or violations. Just agree with the technology police, wait for them to leave and then do what you like. If they come back, just say you are awfully sorry, half-heartedly adopt their recommended technology for an iteration and then refactor it and go back on your merry way.
With frequent short iterations, constant refactoring and lots of reprioritization and business input, the architecture group gets tired of reviewing the constantly changing landscape--and their whole unwelcome presence fades away - Problem solved!
Agile methods have succeeded where reason, laziness and conflict have failed by skilfully blending enough pseudo-science, diversion and duplicity. Agile methods deftly sidestep any common sense questioning that would otherwise expose them as just another set of the emperor’s new clothes. They also frustrate outsourcing models while providing ways to effectively engage the new walking-dead generation of young workers.
This is just for fun, and not what I really believe. I thought it would be entertaining to explore some of the false views that could occur from a casual observance of agile methods. Understanding misconceptions is a useful step in recognizing where people’s views diverge (and then how best to realign them). Please share your own thoughts on agile conspiracies; I would love to hear them.
Note: I first wrote part of this article for GanttHead, and it can be viewed here.