Most Active Stories
All Tech Considered
Tue November 19, 2013
This Slide Shows Why HealthCare.gov Wouldn't Work At Launch
Originally published on Thu November 21, 2013 7:07 am
This is a story of contrast between two popular methods of software development. One is called "waterfall," the other, "agile."
Waterfall development favors listing a huge set of requirements for a system up front, letting developers go away for months (if not longer) and expecting a huge software product in the end.
The agile method does the opposite, favoring work done in phases, delivering "minimum shippable" parts of a software system in weekly or biweekly cycles. This allows for iterating — or adjusting to hiccups discovered in the previous cycle, changing features or quashing bugs quickly and avoiding getting an end product that doesn't look a thing like what your users need.
Like many government projects, HealthCare.gov was developed under the waterfall approach — and to its near doom.
In March, outside consultants from McKinsey & Co. were brought in to do a "red team," or outside progress report, on the system we know as HealthCare.gov. That system includes a data "hub," or pipeline for verification of eligibility; a federal marketplace to shop for plans; and, ultimately, an interface to enroll in health insurance coverage.
The key findings in the presentation (below) come on Page 5. Even though it was written in March, the slide sums up most of the key problems we eventually saw with the rollout of HealthCare.gov last month: limited testing time, evolving requirements, over-reliance on contractors and "stacking" of all the phases of development. The really damaging decision, according to the consultants: launching "at scale." The exchanges for all 50 states opened on the same day, instead of a few states at a time, gradually opening the marketplaces in phases.
Consultants shared this presentation with many key people in the Obama administration, including Health and Human Services Secretary Kathleen Sebelius. The overall document warns of the waterfall approach's many problems for this project, as well as those unrelated to the style of software development process government was using.
Consultants noted there was no clear leader in charge of this project, which we now know contributed to its disastrous release. And there was no "end-to-end testing" of its full implementation, something we now know never happened.
The raw presentation is embedded below, with a few annotations I added for you to explore. You can jump from one annotation to another by clicking on the bolded notes on the right side of this embed. Or you can explore this at full screen.
Update on Nov. 20: We should be clear, even the "ideal" model, on the left side of the featured slide, is just a better version of the waterfall approach. Agile development workflows look more like wooshy circles.