The federal government is traditionally hesitant to adopt ideas that challenge deeply entrenched thinking and practices. But when it does, the energy brought to bear is astounding, and the results are mostly for the better.

One of the latest ideas to catch on with federal IT is agile development, which addresses the pressing need to deliver software projects more reliably, with higher quality and at less cost. This concept is big, and so is its potential. It impacts IT staff, the contracting community, program staff, leadership and procurement. If it's more fully adopted, agile development will alter spending for a large share of the $80 billion federal IT budget.

So what's standing in the way? There are three common excuses used for avoiding a move toward agile development -- but these are more myth than reality.

Myth #1: Agile is new and has to prove itself.

The reality is that agile has been around since the dawn of software development -- as iterative or incremental development -- and has repeatedly proven its value. The bedrock idea of agile development is to grow software by delivering working chunks of code to your customers regularly.

[ What can you learn when an IT project crashes and burns? Read Lessons From A Failed Federal IT Project. ]

All agile values, principles and practices flow from this idea. Project Mercury, begun in 1958, practiced half-day iterations and test-first development. Computer scientist Gerald M. Weinberg, recalling Project Mercury, once remarked, "All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid..."

Leading practitioners of software development from every decade since the '50s have argued that agile-like development is the most reliable way to deliver complex software systems.

Myth #2: Agile is just a process.

Agile teams use processes, but it requires much more -- agile is a set of values, principles and practices in the hands of competent professionals. There is a misconception that says, "If only we followed a process, we could control for success regardless of who's on the project."

There is no substitute for skill in software development. Skill is required to know what practices, processes and tools to use, and that has significant impact on outcomes. For example, the productivity of the top 1% of developers has been measured repeatedly at 10 to 100 times the productivity of the median! Even more telling, it's been estimated that about 10% of programmers actually have "negative productivity" -- under-skilled staff undermine projects.

Myth #3: Traditional PMO methods are compatible with agile development.

Planning without doing will fail to expose most of the risks a software project will face. Moreover, the only measure of progress that matters in software development is working software, not documentation. IT must measure progress by what's been finished, based on doing lots of small things. Leaner, well-run project management offices produce more accurate measurement and projects that are more efficient.

In contrast, the project controls demanded by traditional PMOs are dangerous -- and they're incompatible with agile. Demanding detailed project plans prior to doing any development, and measuring progress by resources consumed and "estimates" of percentage complete is misguided. In addition to generating misleading progress reports, these PMOs substantially increase cost and risk.

Start Now, With Agile O&M

There is no need to wait for the next big new development project to consider agile.

With an estimated 80% of the IT budget spent on operations and maintenance (O&M), leaders need to take a fresh look at their entire portfolio. By implementing innovative approaches such as lean methods of work, agile principles and leaner PMO, and by empowering project managers to be high-tech (using dashboards, for instance) and high-touch (collaborating over working software), government can see astoundingly positive results.

Displacing the deeply entrenched waterfall methods from government will not be easy. IT leaders need to retool procurement and rethink how they staff and manage development and O&M teams. Some organizations have applied agile and lean principles to O&M with great success, as I've seen done at the Federal Communications Commission. The result was increasing productivity and customer satisfaction with fewer resources than before agile O&M.

With those kinds of cost savings and gains in productivity and end results, who can afford not to become agile?