Agile development gets low priority in federal IT

Agile development is a much lower priority for federal information technology professionals than for those in private industry, according to a new survey.

Agile is an iterative model of software development in which work can be done quickly in small increments. It is being applied in agencies including the Defense department, General Services Administration and Veterans Affairs department.

However, the April 19 survey by Serena Software suggests that agile development is limited in popularity at this time.

Only 22 percent of federal IT professionals said agile development was a priority, in comparison to 52 percent of private sector IT professionals, Serena reported. Agile development ranked in seventh place out of nine priorities for government, and ranked in second place for the private sector.

Serena interviewed 225 federal civilian and defense agency IT professionals at a user conference in March. Nearly half of the respondents were IT application developers.

A possible explanation for the disparity is that agile, while generally faster than other models of application development, may be perceived as offering less traceability, said David Hurwitz, senior vice president of worldwide marketing for Serena, said in an interview.

The gap might be due to the “federal government’s emphasis on traceability and audit-ability,” Hurwitz said.

The survey also suggested that the Barack Obama administration’s “cloud first” strategy may not be getting much traction.

Only 19 percent of the federal IT professionals listed cloud as a priority. The interest in cloud also was low in the private sector, where only 21 percent said it was a priority.

The top priorities for the federal IT professionals surveyed were to adopt standard methodologies for application development, listed by 62 percent; deliver applications faster, listed by 57 percent; and automate development processes, listed by 49 percent.

Federal IT application developers work with many tools that do not mesh well together, complicating the process, Hurwitz said.

Developers generally have tools for managing and registering code and for capturing and tracking requirements, but often the tools “do not talk to each other,” he added.

About the Author

Alice Lipowicz is a staff writer covering government 2.0, homeland security and other IT policies for Federal Computer Week.

Cyber. Covered.

Government Cyber Insider tracks the technologies, policies, threats and emerging solutions that shape the cybersecurity landscape.


Reader comments

Mon, Apr 23, 2012 Aletta Austin

Are there any examples of successful Agile implementations in Dod?

Mon, Apr 23, 2012 John Chantilly

Interesting to compare the lack of enthusiasm for agile with their actual top priorities: “The top priorities for the federal IT professionals surveyed were to adopt standard methodologies for application development, listed by 62 percent; deliver applications faster, listed by 57 percent; and automate development processes, listed by 49 percent.” Hmm…if there was only an approach for doing all of this. Here’s what VA CIO Roger Baker told Congress earlier this year: Agile development is important to the VA because it encourages continuous input from our customers. In agile projects, all the development priorities are set by the customer, which ensures that the work is performed in the order of importance. To increase the likelihood of success, large projects are broken down into small but valuable increments, each of which could potentially be a candidate for release. This is consistent with our PMAS delivery requirements. Lastly, agile development requires continuous quality assurance throughout the entire development effort, further ensuring high quality deliverables.

Mon, Apr 23, 2012 BeenThere...

Previous comments are on target, but in addition: Domain experts in government are too rare and too valuable to dedicate the time necessary for agile development. Waterfall fits better with the time availability of the requirement-setting and testing expertise.

Sun, Apr 22, 2012 Too small to get inside attention

Great perspective. The problem is even worse when the government openly and with indifference ignores the policy mandates in recent legislation to use COTS solutions when pursuing insider threat solutions. The new presidential task insider threat force is bogged down by insiders and established systems integrators pushing their own contract vehicles and revenue streams to create GOTS products when currently available other agile COTS solutions are ignored. One need only ask DISA, DARPA, and DoD what they have done in evaluating insider threats in the last year and if they have pursued any pilots of validated solutions. Honest answer is nothing; truth is DARPA identified a solution that has been smothered by ingrained management to protect prior bad decisions and their large corporate friends. The cyber hearings this week would be an excellent opportunity for Congress to expose such administrative lethargy and preferences. As a result of letting only a few play in this critical area, USG decisions are a recurring cycle of meetings to confirm old data without pressing forward to pursue new innovative solutions. A truly agile USG would stop investing in the continual rehabilitation of ineffective and deficient solutions for the sole benefit of contract holders bent on preserving their revenue streams and instead turn to a fair and rapid testing of products offered by smaller and more responsive companies. If the executive branch is incapable of leading the effort, perhaps Congress can -- in the upcoming hearings --at least ask DoD why nothing has been done to address and field test an insider threat solution that DARPA validated as effective, unless of course if doing so will not offend the government's predisposition to curry favor with the politically elite nd connected.

Sun, Apr 22, 2012

Developing software at all within the DoD can be a nightmare compared to the private sector. Ordering developers' computers or even new support license for compilers takes thousands of dollars in labor and weeks of preparation, just to forward the *request* on to Washington. All to get the same outcome in cost and equipment as I could have gotten after 2 hours of market research in the private sector. And then there's complying with the DoD's clueless IA requirements. Even if their requirements were necessary and sensible (both assumptions questionable), they don't provide enough IT staff to make it happen. So instead my projects have their team lead (me), who should be focusing on the technical challenges of the software development project, distracted on a nearly daily basis with issues that people from IT and/or purchasing would handle at a private company. And finally there's the random budget situation, thanks to Congress acting like a bunch of spoiled children, regardless of which party is in power of each house. Ever tried keeping a software development project going when for first 4 months of every fiscal year, your team is dissolved for (temporary) lack of funding? In an environment like this, waterfall vs. agile is the *least* of my concerns.

Show All Comments

Please post your comments here. Comments are moderated, so they may not appear immediately after submitting. We will not post comments that we consider abusive or off-topic.

Please type the letters/numbers you see above

More from 1105 Public Sector Media Group