Agile development faces entrenched resistance
Policies and guidance help move agile development along, but agencies are struggling with challenges rooted in cultural issues.
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.’”