Agile development faces entrenched resistance

Agile development has been plugged as one of the ways government can get the most bang for its buck, but a nimble approach isn’t flawless by any means, according to government officials.

In the stagnant economy and with technology evolving at rapid speed, the agile approach has gained loyal fans in the federal sector. The Homeland Security Department, for example, has embraced agile development practices, and CIO Richard Spires told the audience at the May 15 Small and Emerging Contractors Advisory Forum that “We are really pushing agile. I have half a dozen agile projects going on today.”

The Veteran Affairs Department also looked to agile development when officials decided to develop software to support a new benefit for veterans.

Instead of having lengthy IT projects, projects are split into smaller, easier-to-digest increments that require feedback from customers before moving onto the next phase in the development process. Constant feedback and input from the customer could ultimately prevent projects from running over budget and behind schedule.

The Office of Management and Budget in June 2012 began pushing for an agile approach, and the Government Accountability Office in late July 2012 released guidance on the best practices around it.

But favoring agile over the traditional waterfall approach doesn’t come without its challenges, panelists noted at the AFCEA breakfast discussion, echoing some of the risks and challenges cited in the July GAO report

“There’s a lot of culture that comes into play,” said Shawn Kingsberry, assistant director of IT and CIO at the Recovery Accountability and Transparency Board. “Sometimes, due to culture even if you can the people to the table to be able to actually articulate exactly what the requirements are from the customer, you might not end up with the right results.”

Federal organizations are unique in the way they’re siloed, which creates issues around ownership, he said. “Anyone who knows anything about a matrix organization and matrix processes knows the challenge of ownership – [it’s] ‘mine’ and ‘my stuff,’” Kingsberry said. “Whenever you get into those types of challenges, you’re going to have an issue with information flow.”

It’s also an issue of gaining the trust of the agency leadership and those on the business side, said Tim McCrosson, senior policy analyst at OMB’s Office of E-Government and Information Technology.

“The very first time I embarked on an agile process, I had to convince the CIO that we could do it and truthfully, he thought I would fail miserably or very least fail so he would be able to say, ‘No, we’re not going to do [agile] anymore because you failed so gloriously,’” McCrosson said.

Not only did he have to sway the CIO, but McCrosson had to state his business case to the contracting officer and the business division to ensure everyone was on the same page. 

Agile also forces customers to have clear expectations and stops development projects from snowballing into serious time and money wasters, said Thomas Sasala, CTO at the U.S. Army Information Technology Agency.

“People have been waiting months and months for X, Y and Z, and then you give it to them, it turns out it’s something they didn’t want,” he said. “Either they didn’t know what they wanted or they changed their minds. That’s why agile is so great . . .  instead of investing three months or 10 years on ‘that’s not exactly what I wanted.’”

About the Author

Camille Tuutti is a former FCW staff writer who covered federal oversight and the workforce.

Rising Stars

Meet 21 early-career leaders who are doing great things in federal IT.


  • SEC Chairman Jay Clayton

    SEC owns up to 2016 breach

    A key database of financial information was breached in 2016, possibly in support of insider trading, said the Securities and Exchange Commission.

  • Image from

    DOD looks to get aggressive about cloud adoption

    Defense leaders and Congress are looking to encourage more aggressive cloud policies and prod reluctant agencies to embrace experimentation and risk-taking.

  • Shutterstock / Pictofigo

    The next big thing in IT procurement

    Steve Kelman talks to the agencies that have embraced tech demos in their acquisition efforts -- and urges others in government to give it a try.

  • broken lock

    DHS bans Kaspersky from federal systems

    The Department of Homeland Security banned the Russian cybersecurity company Kaspersky Lab’s products from federal agencies in a new binding operational directive.

  • man planning layoffs

    USDA looks to cut CIOs as part of reorg

    The Department of Agriculture is looking to cut down on the number of agency CIOs in the name of efficiency and better communication across mission areas.

  • What's next for agency cyber efforts?

    Ninety days after the Trump administration's executive order, FCW sat down with agency cyber leaders to discuss what’s changing.

Reader comments

Tue, Oct 2, 2012 Harry Mauve DC

It's great that the government is talking Agile practice and trying to do something about it. While there are many obstacles (procurement, procurement,and procurement come to mind), there is one element that is oft overlooked. Agile practices expose weakness so that the weakness can be addressed. One of the biggest weaknesses exposed is skill deficit in the team. Armed with this knowledge, the team can replace, reassign, or remediate. But, the government has an unholy fixation on hourly rate as the only determinant of procuring app dev staff. Lowest rate is not a good determine if skill - in fact, it's anti-correlated with skill. Until IT management acknowledges the importance of skill in its practice, don't expect much to change. For a summary and some pointers, see:

Fri, Sep 28, 2012

Bottom Line: Requirements need to be documented (from Business Case to Use Case to Test Case to Final Acceptance Testing) so that traceability and financial responsibility are illuminated -- no hocus pocus status accounting.

Thu, Sep 27, 2012 Bud Relihan

I would as "Someone Who Cares" to consider using a robust Product Vision in place of a comprehensive requirements baseline. This allows requirements to emerge as they should through the Agile process instead of being defined in advance which is a recipe for failure. In terms of the justifying payment for the product, I respectfully suggest detailed requirements do not provide financial justification; that is the function of a Business Case, which should guide selection of User Stories from the Product Backlog in order to deliver the most valuable features soonest!

Thu, Sep 27, 2012 Someone Who Cares

The Agile development methodology has some great benefits; however, no matter which methodology is chosen, a mandatory, documented requirements baseline must be established for accountability purposes. Otherwise, you're back at square one, with no one stepping up to the plate to "monetarily pay" for the product.

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