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.
[ Would a cabinet-level department focusing on federal technology help strengthen the U.S.'s position as a global technology leader? Read Do We Need A U.S. Department Of Technology? ]
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.