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.’”

Featured

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: http://www.softwareinsanity.com/2012/10/50-x.html

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