Despite its hype, agile IT practices can’t yet flourish in the federal government, the U.S. chief information officer said.
“I think we’re immature as an industry in really understanding the context in which agile can survive and thrive in a large organization,” U.S. CIO Tony Scott said Tuesday at a Partnership for Public Service event. “We’ve all seen examples where you get a great experiment going and then the antibodies come out and kill it, because it doesn’t look like, it doesn’t walk like, it doesn’t talk like something we’re familiar with.”
By that, Scott means cultural resistance is still agile development’s biggest barrier in federal government. Even though groups like the General Services Administration’s 18F are piloting major agile projects, such as its newly launched agile blanket purchase agreement IT procurement vehicle, the “calcified” waterfall development rituals, as Scott referred to them, are hard to break.
To successfully deliver with agile, the U.S. CIO said the government must “be careful of the context and make sure you set up the right conditions for success.”
Scott stumbled upon agile delivery early in his career: While he was developing software related to theme park attendance in 1979, he was able to work with his customers to rapidly meet their needs. He said, since then, he’s had to carefully structure teams to encourage the same environment.
“As a manager and as a leader, I think setting up the right context and creating the right conditions for success is the most important thing for a leader to do,” he said. “The failure to do that will often lead the inevitable, unintended consequences.”
Agile is not a panacea for faulty IT acquisition, said Brian Reynolds, managing director of Grant Thornton’s global public sector division and another speaker at the partnership’s event. In a later panel, Kathryn Edelman with 18F said agile is great, but “it isn’t the be-all, end-all — it’s not the chicken noodle soup — of all the challenges we face in government.”
“We don’t want to abandon good practice here,” Reynolds said, arguing that traditional waterfall development still has value in certain contexts. Agile, though, works best “where we have uncertainty,” he said. “When we really understand what we want to do up front, then we really need to think about waterfall … or traditional ways of delivering systems. There, we’re focusing on efficiency.”
Scott agreed that agile doesn’t necessarily mean abandoning the efficiencies found in methodologies like waterfall.
“As agile began to take momentum in our profession, some thought of it as an excuse to get rid of things that are just good practice,” he said. “With every new wave, everybody thinks it’s an opportunity to throw out everything and then sort of start over.”
On the contrary, Scott said successful agile development will draw from the successes of traditional techniques.
“Some of the best agile projects I’ve been associated with are ones that borrowed liberally from all the good known practices in waterfall — we just didn’t do waterfall,” he said.