The department needs to do a better job “taking the fear out of innovation,” Chief Procurement Officer Soraya Correa said.
The Homeland Security Department is no stranger to agile and is still committed to the modular software development process despite the failure of its large-scale agile buying experiment.
At a Tuesday event hosted by the technology group AFFIRM, Homeland Security’s Chief Procurement Officer Soraya Correa said the department is still promoting agile software development because “we’ve finally woken up and realized we can’t keep doing [things] the way we were.”
“We can’t continue to let our enemies … get ahead of us,” she said.
Over the summer, Homeland Security notified the Government Accountability Office that it planned to cancel its $1.54 billion agile contracting vehicle, which would have allowed pre-approved agile development vendors to sell their services to government clients. Flexible Agile Support for the Homeland, or FLASH, encountered several protests from businesses that didn’t secure a spot.
But as she continues to investigate opportunities for agile, Correa said a key challenge is ensuring oversight groups “understand what we’re doing, why we’re doing it, how we’re doing it, and [that] there is risk in [agile].” She also said educating “the folks who aren’t the operational folks” about why incremental software development, instead of the traditional waterfall approach, might result in better products.
The department needs to do a better job “taking the fear out of innovation,” she said.
The notion that the government’s biggest challenge in implementing agile is cultural—and not technological—was echoed in a recent GAO report on incremental software buying. While the Federal Information Technology Acquisition Reform Act requires agency chief information officers to certify IT investments as being sufficiently incremental, the process by which they were supposed to certify those investments wasn’t always clear, the report found. And agencies often encountered organizational challenges—for example, not being able to schedule regular product development meetings.