Why Agile can work for complex systems like HeathCare.gov
Connecting state and local government leaders
Development of large, complex systems requires a method that also allows a progressive discovery of project scope and dependencies, along with identification and mitigation of key risks.
Agile software development has taken some hits in the recent discussions of HealthCare.gov’s failures. But implications that, because agile development discourages “big design up front,” it is inappropriate for complex systems paint an incorrect picture.
These misconceptions about agile methodology — that it‘s unstructured, lacks documentation or only works for small projects — couldn’t be further from the truth. Some people have a “developers gone wild” image in their minds, despite the fact that research has clearly shown that the success of agile projects is three times that of waterfall projects.
So how would a complex project be tackled in an agile manner?
Complex projects must overcome significant external factors and challenging functionality. Government systems, such as HealthCare.gov, face complexity on a large scale: new laws, politics, multi-agency and multi-organizational dependencies, capability on a massive scale, new teams. The building of a new system must be the product of successfully navigating all these issues.
That navigation cannot be accomplished, in total, by upfront requirements definition and system design. The complexities noted above require a method that also allows a progressive discovery of project scope and dependencies, along with identification and mitigation of key risks. While some challenges can be solved in advance, many require the actual problems to arise before solutions can be discovered, circumvented or negotiated with external parties.
For large systems — ones which require multiyear efforts — an agile approach must address all of these significant complexities and dependencies. Yet, success is not solely based on process. Team members must have skills in agile methods, demonstrated by successful track records delivering working systems.
Those skilled agile teams often use the Unified Process (UP). Agile and UP are, in many ways, the perfect marriage — both are based on highly iterative problem solving and software delivery. While agile practices focus on adapting to change and new information, UP sets up a four-phase approach that organizes agile activities for large-scale development. While agile practices foster problem solving, collaboration and adaptation on a small and iterative scale, the four phases of UP help navigate the complexity of a large-scale project.
1. Inception: The depth and breadth of the project are established — the business case, potential solution approaches, key risks and identification of a core team.
2. Elaboration: A core team is staffed, significant requirements are characterized and the technical approach and key risks are determined by building initial software to validate key assumptions and risks. A development plan sets up the next phase.
3. Construction: The significant portion of the system is iteratively built, tested and delivered. Software is fielded, typically with overlap to the transition phase.
4. Transition: Software is delivered to the target user base, again iteratively, validating functionality and solving issues that can only be resolved through actual use.
By focusing on solving actual problems through iteratively building and delivering software, skilled agile teams can surface, negotiate and resolve complex challenges and external dependencies. The ultimate measure of progress is working software. Fielding the most challenging aspects of a system early and performing break-fix iterations along the way are keys to success. In this regard, agile development would not have contributed to the launch of an unproven HealthCare.gov system – rather it would have surfaced those key issues far sooner in the creation of the system.