This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Agile isn’t academic. Still, beware the ‘pragmatists’.
There’s a perception that agile is somehow academic – that it was cooked up as part of a PhD dissertation, or is the rarefied result of years of private funding and fevered intellectual inquiry by ivory-tower eggheads at some software equivalent of the Brookings Institution. Unfortunately for anyone subscribing to this misperception, the exact opposite is true. The folks that came up with agile practices did so out of long experience and frustration with the failures of the dominant method of software development, waterfall. And ironically waterfall itself owes its popularity in large part to the seductiveness of a theoretical approach.
Nevertheless, the perception persists. A disappointingly common result – used in defense of reluctance to shed unproductive habits, roles, and expectations preventing organizations from being more agile – is an appeal for a need to ‘be pragmatic’. This is odd, because agile is the most pragmatic approach to software development anyone has yet articulated. It doesn’t conflate the inherently chaotic, unpredictable, creative process of building software with a stable, predictable process like building a house or a bridge. It doesn’t confuse the subjective and infinitely changeable – even personal – success criteria of most software development with the objective and immovable criteria of say, mathematics or physics.
Unfortunately none of this means it’s easy to implement against the inertia of existing structures and decades of embedded assumption. But at what point is ‘being pragmatic’ simply an excuse for not trying to change?
In the face of repeated failure, wouldn’t the pragmatic approach be to try something new that might offer a chance of improvement? Most large organizations investigating agile are in a crisis state of perpetual project failure already, so they’re not actually risking much except the ability to blame the usual suspects. It’s not the risk of failure they fear – It’s the discomfort of change that’s the scary part. It’s the pain they know versus the one they don’t.
So many react to agile like the Frenchman in the joke about an American and a Frenchman struggling to craft a solution to a complex problem: The American drafts a straightforward but unconventional solution and passes it to the Frenchman, who examines it, frowning and puzzling over it at length, rereading it again before shaking his head and passing it back, saying: “This solution works in practice, but I’m afraid it doesn’t work in theory.”