The rollout of HealthCare.gov, on October 1, 2013, was a famously bad day for the Obama administration. HealthCare.gov is the marquee website of the Affordable Care Act—the portal through which Americans can access insurance exchanges that the federal government created under that landmark legislation. But on the first day, heavy use crashed the site repeatedly, and those who managed to reach the site encountered further frustration when they tried to use it. Ultimately, only six people were able to enroll in an insurance plan before the day was out.
More than 50 contracting companies took part in developing HealthCare.gov, and their work cost US taxpayers nearly $800 million. But according to Mikey Dickerson, a former site reliability manager at Google, the site should have cost as little as $60 million to build.
And he should know. Dickerson is now the administrator of the United States Digital Services (USDS), the group that eventually fixed HealthCare.gov. He and others at USDS bring Silicon Valley experience to their work, and that experience has immersed them in the practice of agile development—a method that involves creating, testing, and improving technology products incrementally. That approach contrasts with the typical government procurement process, which aims to deliver a foolproof product regardless of cost.
In the spring of 2015, the US Department of Veterans Affairs (VA) sought to develop a website to help veterans find employment. The VA, following the standard procurement process, got an estimate of $25 million to create the site. Then the VA went to Dickerson’s team at USDS, which did the project for $175,000. USDS, a group of about 70 people, focuses on digital projects that advance top items on the Obama administration agenda. It’s a high-profile outfit, with offices close to the White House.
A less heralded group of technologists is spreading the agile development model to far corners of the US federal government. This group does its work not in the vicinity of the White House but in the belly of the bureaucratic beast. Its headquarters is on the sixth floor of the General Services Administration (GSA) building, a sprawling complex that occupies an entire block at 18th and F Streets in Washington, D.C. It’s a unit within GSA called (aptly enough) 18F. The 18F team includes about 150 people who—like their counterparts at USDS—left jobs at Facebook, Google, and other technology companies to become federal employees. Making government work better is more compelling to them than making lots of money.
The purpose of 18F is to help federal agencies improve the way they build and buy information technology (IT) services. “Basically, we’re making our clients into better clients,” says Hillary Hartley, cofounder and deputy executive director of 18F. (Hartley now works out of a satellite office that 18F operates in San Francisco.) “After they go through an 18F process, they know what to do, what questions to ask, and what to expect the next time they have to buy IT services. We help them get smarter.”
“Delivery Is the Strategy”
At any one time, the 18F team has as many as 30 projects under way for clients such as the US Department of Homeland Security and the US Department of the Treasury. The team works with these clients on a fee-for-service basis, and it brings to each project a well-honed method of practicing agile development. For people from Silicon Valley, following this model is a no-brainer. But for people in government agencies, it’s often a big mind shift. Central to the 18F method is a process that unfolds in four phases.
Phase One is the deceptively simple-sounding discovery phase. A team of 18F developers shows up at a client agency and tenaciously digs into a project in order to discover the client’s real, underlying needs. Members of the team hold focus groups both with agency staff members and with end users, and they meet regularly with agency leaders until they understand the kind of product that people will actually use—and, equally important, how people will use it. From the start, in short, the 18F process incorporates the principles of user-centered design.
Phase Two is called alpha, and it involves building a prototype product. In the case of the Federal Election Commission (FEC), for example, 18F helped the agency overhaul FEC.gov, its main website. For US Citizenship and Immigration Services, the group developed a new process for renewing Green Cards. During this phase, collaboration between the client team and the 18F team is especially close, and clients learn the full meaning of 18F’s informal motto: “Delivery is the strategy.” It’s a variation on “The strategy is delivery,” the motto used by the Government Digital Service, a comparable office within the UK government. But it alludes to an idea that’s common in Silicon Valley. “It means doing and not talking,” says Shashank Khandelwal, director of data and technical architecture at 18F. “It means that instead of doing this thing that government does—where [people] talk for a long time about a project before they embark on it—we say, ‘Let’s build it, and let’s build as little of it as possible at a time, so we can prove that the thing works.’”
Video: Shashank Khandelwal, director of data and technical architecture at 18F, describes how 18F teams spread the practice of agile development to its clients in the US federal government.
Phase Three, called beta, is perhaps the most challenging part of the process for federal employees. In this phase, 18F developers and their agency partners improve the product iteratively and then test it publicly. It’s the moment-of-truth phase, and agency partners often approach it with dread. Sarah Allen, a product manager at 18F, describes “an atmosphere of fear” that pervades government bureaucracies—the fear, in particular, of rolling out a product that doesn’t work perfectly. Yet in trying to avoid error, these bureaucracies “actually end up creating huge failures” like HealthCare.gov, Allen notes. “In an effort to make things go really well, they significantly increase the risk that things will go terribly wrong. They think that they need another round of edits, another version. ‘No,’ I tell them, ‘What you need to do is fail fast.’”
Phase Four, the live phase, occurs when the fully developed product becomes operational for all end users. When the first three phases go well, this phase marks the culmination of a successful IT project. In September 2015, for example, the Obama administration proudly launched a new version of College Scorecard, a site where students, parents, and guidance counselors can easily compare one college or university with another. To build that product, 18F worked with the US Department of Education, the Treasury Department, and the Internal Revenue Service. Now, with just a few keystrokes, users can find out how much it will cost to attend a given school, the odds of graduating from that school, and an array of other comparative data.
“Much More Than a Website”
For technology industry veterans, working at a place like 18F offers the satisfaction of creating products that have an outsized impact on how Americans experience their government. Take Hartley, for example. Earlier in her career, she spent more than a dozen years at NIC, Inc., a company that provides information services to federal and state governments. Working inside the federal government is a much different proposition, she says: “It’s really motivating to know that we are fundamentally changing a system—and intoxicating to know that the thing we build is going to be used by millions and millions of people.”
For 18F clients, meanwhile, working with 18F offers its own set of rewards. Larry Mathias is the IT liaison for OASIS (One Acquisition Solution for Integrated Services), a system developed by GSA to manage complex procurement contracts. His group asked 18F for help to build a tool for that system. During the discovery phase, members of the 18F team conducted customer focus groups. “They came back to me and said, ‘Larry, that ain’t gonna work. All the customers said, Nope, we already have that support, so we couldn’t use your [tool],’” Mathias recalls. “So we dumped everything [that we had already done] into the trash bin, and we built what the customers wanted.” Mathias estimates that 18F completed the project for one-third of the cost that would have resulted from using traditional methods to develop the tool. “But don’t get hung up on dollars,” he says. “Because even if I’d spent [far more than I did], I don’t know that I would ever have gotten the product that I got.”
For Wei Luo, chief information officer at the FEC, working with 18F was a revelation. In 2014 and 2015, he headed a team that worked with 18F to overhaul FEC.gov. “We didn’t even know where to start,” he says. Then developers from 18F took FEC commissioners, staff members, and site users through the four-phase agile development process. “In the end, we got so much more than a website,” Luo says. “We had a complete culture change about how to do user-centered design.”
The federal government has come a long way in less than three years. The legacy of the HealthCare.gov fiasco is a fast, cost-efficient method of developing IT products that meet the needs of both government agencies and the citizens whom they serve. “There was a come-to-Jesus moment after the HealthCare.gov debacle,” says Ben Scott, former policy advisor for innovation in the US Department of State and now a senior advisor to the Open Technology Institute at the New America Foundation. Afterward, Scott explains, the Obama administration “really started institutionalizing the spirit of innovation and technology in government. And the notion that government would not only adopt these methodologies but do so successfully means that we could see a cycle of change in government services that is analogous to the speed of adaptation that information technology has brought to other parts of society.”
Video: Lindsay Young, a developer at 18F who formerly worked at the Sunlight Foundation, discusses the benefits of deploying her skills not as an outsider but as a government employee.
Alexandra Christy conducted and produced the video interviews embedded in this article. We feature them here with her permission.