US Digital Service: Key To Making Government Agile?

Effort to apply the lessons of HealthCare.gov is praiseworthy, but may not get at the root cause of problems with digital government services.

David F Carr, Editor, InformationWeek Government/Healthcare

August 14, 2014

4 Min Read
Motherhood and apple pie <br />(Source: Scott Bauer, USDA ARS, via <a href="http://commons.wikimedia.org/wiki/File:Motherhood_and_apple_pie.jpg#mediaviewer/File:Motherhood_and_apple_pie.jpg" target="_blank">Wikimedia Commons</a>)

while Agile is the preferred methodology for digital services development, federal contracts are too often built around rigid requirements that conflict with the Agile principle that requirements must often be discovered through the iterative development of working code. The solution is to build contracts around a high-level vision for a project that includes the business results the software must deliver, without being too prescriptive about how the software should function, the authors state.

"What Mikey and his team seem to be doing is thinking of Agile as a software-development process, and it's not -- it's a business process," Fisher said. "In government, Congress and the leaders of the other organizations are the business owners, and as far as I know, they're not following Agile, so it's destined to fail."

Agile works when not just the software developers, but also the business leaders understand that a digital service needs to evolve to be successful, he said. Sometimes that means altering business goals to match the reality of what's practical to deliver in software or take advantage of opportunities that only become obvious once software development is underway. That's not the way government typically works, certainly not with a massive project like HealthCare.gov with requirements hard-coded into legislation. In any project with big ambitions, Congressional leaders and agency heads are likely to insist on knowing exactly what they're going to get for their money before they put a project into the budget.

"It's on the procurement side, which is more of a waterfall, where the conflict is going to come in," Fisher said.

Is Mikey Dickerson's leadership of the USDS likely to change that? Probably not.

"Taking a look at Mikey's background, he's a great guy, but he's an engineer, he's not an executive that's going to do battle and fight some of those [structural] issues," Abbott said. "Fixing that problem isn't the job of a well-respected engineer or lower-level manager. It's the job of a skilled senior executive (which Mikey is not) with political aspirations." If you wanted a Googler to fix government, you'd need someone more like executive chairman and former CEO Eric Schmidt, he and Fisher suggested.

(Hard to imagine that Schmidt would want the job.)

Another key structural issue, which the Digital Services Playbook does address, is: "Assign one leader and hold that person accountable."

It's good that's on the list, because a vague and confusing division of responsibility and authority was one of the key failures of HealthCare.gov, Abbott said. But making it happen would likely require some head-banging, he said. "Again, who is going to enforce this?"

Later in the conversation, Abbott hedged a bit, noting that the USDS could still make a positive difference. While he generally endorses Agile, it's not the only route to software success, and government projects wouldn't necessarily have to meet a purist's definition of Agile to get the benefits of a more iterative approach to software development that allows for some course corrections.

"We're big believers in Agile, and try to get our client partners to adopt it where it makes sense, but the engine has to match the transmission," he said. If you can't fix both pieces, "you're better off getting a transmission that fits the engine," with a hybrid that includes elements of the traditional "waterfall" model with requirements defined up front, he said.

There are other theories of how the digital playbook misses the mark. FCW columnist Steve Kelman suggests the problem with procuring Agile development services is more at the level of the task order than the contract. The USDS is inviting comment on its playbook and acquisition guidelines, and Kelman said he planned to submit his thoughts as part of that feedback process.

The USDS is less than a week old, which is awfully soon to be pronouncing it destined to fail. At one point, Abbott told me, "They're claiming they're fixing everything, but they're really fixing a small delivery piece of it." To be fair, VanRoekel is only claiming a modest beginning, a pilot project to make things better.

But Agile government? That's a tall order.

IT leaders who don't embrace public cloud concepts will find their business partners looking elsewhere for computing capabilities. Get the new Frictionless IT issue of InformationWeek Tech Digest today.

About the Author

David F Carr

Editor, InformationWeek Government/Healthcare

David F. Carr oversees InformationWeek's coverage of government and healthcare IT. He previously led coverage of social business and education technologies and continues to contribute in those areas. He is the editor of Social Collaboration for Dummies (Wiley, Oct. 2013) and was the social business track chair for UBM's E2 conference in 2012 and 2013. He is a frequent speaker and panel moderator at industry events. David is a former Technology Editor of Baseline Magazine and Internet World magazine and has freelanced for publications including CIO Magazine, CIO Insight, and Defense Systems. He has also worked as a web consultant and is the author of several WordPress plugins, including Facebook Tab Manager and RSVPMaker. David works from a home office in Coral Springs, Florida. Contact him at [email protected]and follow him at @davidfcarr.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights