Traditional development methods require programmers to meet complex requirements using rigidly defined procedures and a narrowly prescribed tool set. Such “waterfall”-based projects typically miss deadlines, bust budgets and deliver systems that no longer reflect business needs. Agile development methods are different.

Indeed, according to their proponents, agile methods are everything that traditional methods are not. They do not encourage programmers to respect routine and administrative diligence above creativity and spontaneity, nor do they, as traditional methods do, isolate developers from the people who are expected to use what they build. Best of all, agile methods encourage an iterative approach to functional delivery that is rarely late, virtually immune to expensive requirements bloat, and almost guaranteed to produce something that is fit for purpose.

So, surely everyone is going agile? Not quite. Despite mature roots – in the dynamic systems development methodology (DSDM) popularised by ISVs in the mid-1990s – agile programming is still scarce in enterprise development shops. Just 21% of this year’s Effective IT Survey respondents use agile methods, and Gartner estimates that barely 5% of new home-grown business software is produced via agile means.

Several factors have contributed to this poor penetration of enterprise IT shops, not the least of which is the tendency for agile proponents to evangelise in purist terms, insisting  traditional methods have no place in the agile hereafter. “Nonsense” is how Gartner characterises these claims, but other barriers to agile adoption are less easily dismissed.

Take budgeting: accurate estimation of conventional development project costs is notoriously difficult, but it can be done. In the interactive, iterative world of agile development, managers are faced with predicting the cost of projects that have no precisely pre-defined goals or deadlines. For many financial planners this makes funding an agile project look less like an investment, and more like a blind act of faith.

However, set against the potential benefits that agile has to offer, all of these so-called barriers should only prove to be minor obstacles.