Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Mar 31, 2012 — Enterprise Agile Planning expert

Agile isn’t academic. Still, beware the ‘pragmatists’.

Enterprise Agile Planning


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.”


More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us