When it comes to buying and delivering government technology projects, few approaches seem to have caught the attention of federal officials the way agile development has.

And there’s good reason, according to management specialists from the Department of Defense, the Department of Agriculture, the FBI and the General Services Administration who spoke at a Washington forum Oct. 14 about how agile development is making inroads in government.

Senior managers see agile development–which breaks IT projects into shorter, more modular development cycles–as a way to deliver new IT services faster and provide a better return on investment.

Project leaders find agile development can provide a more efficient and more disciplined way to meet the needs of stakeholders compared to the alternative–delivering entire projects months or years after they were commissioned.

Even accounting and contracting managers are beginning to see the potential for real cost savings associated with agile development. That’s in spite of the fact that rapid iteration and review development cycles amount to round pegs being forced into the square holes of traditional financial and acquisition controls intended to track big government IT projects.

According to a recent Standish Group study highlighted in an August 2011 presentation from the Defense Information Systems Agency, nearly two thirds of the features built into software projects are never or rarely used. The study also showed that less than 3 percent of projects budgeted to cost more than $10 million are delivered successfully, while nearly half budgeted under $750,000 are delivered successfully.

Agile is not code-and-fix
“If you know what your requirements are, and that technology isn’t going to change, and you know what your customers want, then you might not necessarily need agile development,” said Rob Vietmeyer cloud computing portfolio manager at the Defense Department.

“But in this day and age, we’re guessing what users want; we’re speculating what the technology will be like and what the interfaces will be like in this environment. So, if you can’t define those things, then you need a process that can adopt changes,” said Vietmeyer, who prior to joining the DoD Office of the CIO had led the DISA’s pioneering Forge.mil program, which fostered rapid, open-source software development.

“That doesn’t mean there’s not a lot of rigor to the process. People think this is code and fix. It’s not,” he said, explaining that agile development requires both highly disciplined planning and continuous buy-in and review from stakeholders.

Tyler Bond, senior information technology specialist/project manager, USDA, concurred. It’s essential “to get the users involved” throughout the entire process, to “ensure they get what they want in the end,” he said at the forum, hosted by AFFIRM, a government technology education trade group.

Each stakeholder has to be part of the agile team, working on a daily basis, so everyone is familiar with each iteration.”

Different management style
Managing agile development is significantly different than the more traditional waterfall approach, said Robert White, supervisory computer engineer, FBI.

“With the Waterfall (method), you have a very linear approach,” he said, which stretches the sequence of specifying, contracting, designing, building, testing, reviewing, revising and delivery over a long timeline. “With iterative development and incremental delivery, you’re going to need different types of analysis,” which he said needs to be more “trigger based.”

Another crucial aspect of agile development is the need to break down the traditional approval process and roll it into each iteration cycle, said Vietmeyer. That means “each stakeholder has to be part of the agile team, working on a daily basis, so everyone is familiar with each iteration. Then you hold that team accountable for that delivery, for their piece of the process, during the iteration period,” he said.

“With agile projects, you’ve got to break every request, feature and desire down into an increment of time, with a point value,” said Vietmeyer, explaining his teams assign points to tasks that require a few hours, a day or three or more days. “When a request comes in, you estimate (its impact on) the team velocity,” Vietmeyer said. “So if a bug comes in, and it requires a three-point effort, you look for the trade off,” he said.

Capping the points per iteration and holding stakeholders accountable to deliver iterations on schedule helps the team focus on the top priorities-or go to the project’s sponsors for more resources “when a four-star (general) comes in and says he wants this or that,” said Vietmeyer.

Importance of automation
Another aspect of agile development, USDA’s Bond stressed is “the importance of automated testing.” Agile development can be more expensive than traditional development because testing and reviews are done more frequently. “So one way to reduce costs,” he said, is to use available testing tools, “so you don’t have to pay people to do the testing all the time.”

One of the challenges of agile development, the experts said, is keeping up with the documentation and other tracing artifacts that accompany IT projects.

“We don’t have a requests traceability system,” for agile projects at the FBI, said White.

Vietmeyer agreed: “The level of documents and conversations is completely different than if you release something every for review ever six or 18 months,” he said. He acknowledged his teams are no longer completing traditional reporting spreadsheets and documents, relying instead on automation to keep track of individual tasks that are open or closed.

The acquisition challenge
Perhaps the biggest challenge of agile development is how to buy services to support it, since acquisition procedures often don’t lend themselves to rapid iteration cycles and short-term bursts of applied specialty skills.

Vietmeyer said he and his teams still do not have contracting officers who are comfortable with agile development. What’s worked best for Vietmeyer is to use existing GSA contracts to buy fixed amounts of hours of technical expertise from vendors who can provide a variety of needed skills, where experts can come in and work on a specific task or another for limited periods of time.

Mindy Connolly, chief acquisition officer, GSA, who also spoke at the forum, acknowledged that contracting officers “need to be focused on outcomes. If there are burdensome processes that aren’t contributing value, we need to find other ways to get to the outcome. Agile development may actually help bring coherence to this process,” she said.

As the administration, including the U.S. Comptroller, have been reviewing why the development of federal financial systems have been over budget and behind schedule, one observation “so many people took away” she said, “was how can we buy smarter. And the concept (for improvement) was to do it in smaller bites.”

Vietmeyer, speaking after the forum, said that perhaps an even greater force driving the push to agile development, beyond the economics, is the rapid escalation of security attacks on government IT systems. The attacks tend to make agile teams more responsive to the need for rapid changes even in legacy systems, he said.