Translating Policy into Software — The ACA as Requirements Document

In their attempts to build robust policy, the architects of the ACA also hamstrung the creation of the healthcare exchange websites. As a controversial piece of policy, the ACA maximized robustness and used specificity as armor against malignant misinterpretation. Unfortunately, this also clashed with the Agile development process used to create the exchanges. In Agile, requirements represent the mutual understanding of stakeholders and developers and as a result must also be flexible and iterated on.

Here are three quick improvements that would have streamlined the implementation of the healthcare exchanges and that may be useful for future government collaborations with software.

  1. Provide provisions for delays. As written, failure to create an exchange by January 1st, 2014 demands the Secretary find a replacement implementation (most likely the federal default). No mention is made of granting extensions or salvaging the previous work.
  2. Use phases or milestones to prioritize different requirements. The ACA policy demands that every single requirement is satisfied in order for the project to be considered “done.” In reality, not all features are created equal. If the user feedback feature isn’t done, the project shouldn’t be scrapped. Definitions of done should be split into phases to delineate different tiers of priority.
  3. Share expertise. During the initial planning stage of the ACA, allowing someone with expertise in software development to give comments would have provided another valuable perspective. Similarly, during the development process of and the state exchanges, political entities could have embedded a representative into the software team to serve as the “product owner” by providing rapid feedback.
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.