“And I’m like, how is that agile? That’s a three-month plan—down to like, a plan every day of those three months. ‘What if you learn something on like the third week that changes the rest of the plan?,’” Yu remembers asking. “And they were like, oh, well it’s the rest of the plan, so it can’t change.”

This tension became clearest during a tussle over deadlines. The MPL team chose not to launch App2 with a single big oomph. Instead, it rolled out the app in stages: first, to zero percent of users; then, to one percent of them; 10 percent; 20 percent; all the way up to 100 percent of users. These launch targets were just targets, and even more so, they were estimates. They could be shuffled around or imperfectly executed: The goal was to establish a product that worked and was online and could be improved on.

And, in the run-up to the zero-percent target, the MPL team began to change the parameters. Developers realized they could drop one planned feature in exchange for totally fixing another, and they notified their government bosses that this is what it planned to do.

“We thought it wasn’t a big deal,” Yu told me. But the government, he says, replied with a message like: “How can we launch to zero percent of people if those things aren’t done?”

“There’s whole tiers of organizations especially in these large contracting organizations that do nothing but manage the schedule, so if the schedule is slipping, that’s their highest alarm bell going off,” Bhobe says.

It was partly a communication failure: The team had not fully understood the government’s assumptions about what a release date should be. But it also revealed how the government did not understand agile, even as it said it valued the technique. (Officials with the Department of Health and Human Services declined repeated requests for comment.)

It was not the government’s first time trying to be agile during the development of Healthcare.gov, either. Some of the original contracts for the website specified that contractors would follow an agile technique so as to develop software more quickly. It was many of these same contracts that went awry and created vast cost overruns. According to the Government Accountability Office, that happened because CMS failed to do proper oversight on them—struggled to know how to do oversight on agile—and because these contracts were also “cost-plus-fixed-fee,” where the contractor was reimbursed for costs it encountered while making the site. The MPL team’s experience seemed to show that even with teams more experienced at agile, many government employees struggle to adapt to the process.

* * *

Instead of building a marketplace app, the team instead created a new application for health insurance. Though designed at first just for call centers, the new app proved so popular that eventually CMS rolled it out to everyone with an uncomplicated medical history. About 65 percent of all new users wound up using this “App 2.0.”