Why Feds Are Embracing Agile

Agile development can save costs, but it also can help improve the position of the CIO and the IT organization in the agency.

Numerous federal agencies are moving to Agile software development methods for some or all of their IT systems development projects. In an era of tightening federal budgets and increased demand on technology to help meet mission requirements, agencies are searching for ways to deliver critical mission functionality more quickly and with less risk. For a number of agencies, Agile has become the answer.

On its face, the case for Agile is straightforward: Break the software development process into a series of short "sprints," each of which delivers on a small portion of the requirements of a system. This modular approach enables (and encourages) frequent delivery of new functionality to end users, and facilitates (even demands) user participation and feedback during system creation. In contrast, the "Waterfall" development approach used traditionally within government requires users to be able to fully describe what they want in a system up front and to wait years until the system is finished.

Agencies typically adopt Agile to avoid large-scale failures in systems development programs. The Department of Veterans Affairs (VA), an early adopter of Agile in the federal government, moved to Agile in 2009 for a critical new system (the New GI Bill) when the department was failing on much of the rest of its development portfolio. As a result, VA successfully delivered its first new large-scale system in years, and decided to adopt Agile for the development of a number of other critical systems.

Agencies are also moving to Agile to better ensure that the system being developed actually meets the needs of the mission. Programs using Agile development provide customers with early production versions of the product to use and critique, ensuring customer involvement and buy-in. More importantly, because change happens, Agile's frequent releases provide the ability to rapidly respond to changing mission priorities, customer preferences, or even requirements imposed by new laws.

Critical to today's federal environment, Agile also cuts system development costs. Frankly, this can be the hardest to justify. The initial estimates for the cost to develop a system using either Waterfall or Agile are likely to be the same. Logically, if both processes work as well in practice as they do in theory, either process should result in the same system for much the same price. In reality, metrics show that incremental programs (including Agile) successfully meet their delivery commitments at a rate nearly three times that of Waterfall. In my experience, this equated to on-time delivery jumping from under 30% to over 80% for a $1 billion systems development portfolio.

Using Agile for systems development frequently has an immediate positive impact on mission results. By delivering and then improving production versions of a system early in the development cycle, Agile programs allow the agency to begin realizing the benefits of the new system to their missions much earlier. And with system users intimately and continually involved in its design and development, the end solution better addresses their real-world requirements, allowing them to work more productively.

Finally, using Agile can help improve the position of the CIO and the IT organization in the agency. With daily active engagement between users and IT, and frequent on-time delivery of new, mission-prioritized system functionality, customers start to see IT as a full, essential and productive partner in accomplishing the agency's mission. And that has substantial implications during the budget process, during resource discussions, and on the agency's willingness to give more authorities to the CIO.

After all, IT is an investment in improved mission effectiveness. If they see that investment returning frequent, reliable, positive results, they're going to look to find more ways to invest.

Roger Baker is chief strategy officer for Agilex, a leading provider of mission and technology solutions to the federal government. He was previously CIO for the Department of Veterans Affairs from 2009-13 and served as CIO for the Department of Commerce from 1998-2001.

I completely agree. I had to work on a couple of big projects using Agile and they were basically all meetings and tons and tons of re-writing. Not doing requirements and design at the beginning is a big problem when building large, complicated systems. Agile was a fade that has hopefully passed...

I think one of the key points here is how agile is way to reduce wasted spending in Government IT. I think Roger's comment above is worth repeateing: "In reality, metrics show that incremental programs (including Agile) successfully meet their delivery commitments at a rate nearly three times that of Waterfall. In my experience, this equated to on-time delivery jumping from under 30% to over 80% for a $1 billion systems development portfolio."

After spending quite some time on agile teams I came to the conclusion that agile is a nice label for being in "startup company" mode indefinitely. All projects I know of that went agile took longer to complete, had lower quality, and frustrated everyone involved. There is too much process with most of the agile approaches, even more than with a flexible waterfall. Too much time is spent on rework because the idea catches on that we can be totally iterative and make changes at any time. Zero thought is put into up front design, requirements gathering, spec writing, and proper documentation. Three months later nobody knows why things were done or weren't done, so you start over reinventing the wheel. Agile generates an excessive amount of churn and rewards those who never want to make any final decisions. Plus, stuff is never done because there is always the next sprint and the next iteration. And with all the demos and discussions and gazillion meetings any agile team looks busy and comes across collaborating like never before, but any real work of value just doesn't get done.Agile is a fad that gets happily picked up by managers to demonstrate that they can act rather than react and are willing to go with something modern. It rarely is an organic change where development teams are unhappy with the process used and agree that agile might be worth a try. Maybe that is why most agile projects are a constant failure? Agile is fine for apps that are very small in function and scope, that are intended to be thrown away within a year, and that do not require any support or maintenance for a longer period of time. So for the dinky mobile apps that all are one trick ponies agile might work out, or for features on a social network that can be yanked at any time. For anything that amounts to a real application that is intended to be in use for years agile just brings more baggage and disadvantages then it might provide in benefits.

I think agile has won the hearts and minds of developers over older methods. Some people say its still the province of startups and avant gard companies but I disagree. Its penetrated many if not most enterprise development teams. The government agencies are late to the party.on agile.

There's no doubt Google has made headway into businesses: Just 28 percent discourage or ban use of its productivity ­products, and 69 percent cite Google Apps' good or excellent ­mobility. But progress could still stall: 59 percent of nonusers ­distrust the security of Google's cloud. Its data privacy is an open question, and 37 percent worry about integration.