Just about every Agile expert on the web is decrying the use of a Waterfall development methodology as the downfall of the Healthcare.gov open enrollment website. But based on one knowledgeable account, it appears that the development team was using Scrum, however badly. Government Computer News published an article by Michael Daconta, the VP of Advanced Technology at InCadence Strategic Solutions and the former Metadata Program Manager for the Homeland Security Department, that largely skewers the Agile-would-have-prevented-this meme. The article drew a comment by Agile Manifesto signatory Bob Martin, who assures us that “a project that fails to allow users to log in on the first day of launch was not developed under the auspices of an agile process.” Unless they really sucked at it, or it was inappropriate for the problem at hand.
I’ve read a bit about the system, and it appears that many of the underlying problems are a result of the complexity and sheer number of the integrations between the various insurance companies, state and government agencies, and the central hub behind the excellent, highly reliable user interface. Paul Smith’s account is particularly enlightening. Note that the hub and UX were developed separately, by different contractors.
Lawyers, Programmers, and Money
The people who did the content management for the front end were a 12-person shop in Washington DC, Development Seed. They were brought in by someone with White House influence, who liked their Open Systems approach, on what sounds like a sole-source contract. The Health and Human Services (HHS) CTO, Bryan Sivak, spoke about their technical approach at South by Southwest. Even Bob Martin would admit that they’re Agile. Their CEO said that they declined to bid on the rest, because they don’t have the legal staff to handle a federal competitive procurement.
I suspect that when the final analysis is available (assuming the government and their contractors don’t classify it top secret), we’ll see that the technical challenges were exacerbated by the federal government’s procurement system. The work on the hub was bid on by several companies with dedicated federal government sales organizations, which allowed them to respond to a government solicitation. The bidder’s list was limited to a small number of firms with federal government software development experience, rather than experience developing open enrollment websites. I’d guess that the long delay inserted by the contracting process, plus the fact that requirements were being driven by state and federal legislation that kept changing, plus delays and uncertainty driven by the participation by attorneys who had to analyze every aspect of implementing the new law, plus the continuous changes in what the insurance companies were offering, plus the extensive integration work and widely distributed business logic, made timely development and thorough testing impossible. But that’s strictly my guess, as an outside observer.
Observations From a Practicing IT Project Manager
Of course, the apparently inadequate risk management jumps right out at the experienced project manager. You have a big bang delivery, on a fixed go-live date, and no contingency plans? No provision for paper forms or intake by some call center? Or a way to let tire-kickers window-shop without entering the personal data that has to be validated by the Social Security Administration, Homeland Security, and so on? Or a way to bypass certain synchronous edits, for follow-up in case provided information is found to be invalid? It’s all do-or-die? So, how do you like death?
I’ve implemented benefits open enrollment administration systems for about a dozen companies using several technologies, including PeopleSoft and Workday. Even with one employer, a limited number of choices, a small number of integrations, and a configurable, mature product with lots of previously successful installations, it’s not a trivial exercise. This project appears to be three or four orders of magnitude more complicated. I don’t think any software development methodology could have made a difference, absent a highly skilled architecture team with lots of application-relevant experience preparing a design that would accommodate all of the potential integrations and logical combinations, and a product management team with absolute authority to make decisions and enforce them. But, only Congress was allowed to make the key decisions. And as product owners, they have a well-deserved bad reputation.