This is the third of a six-part blog series is derived from a recent article in Public Administration Review, Balancing Digital Transformation and Modernization: Pathways for Public Managers, by Marc Picavet, Kevin Desouza, Greg Dawson, Jim Denford, and Dan Chenok. Read the first and second blog.
Advocates of agile modernization methods often point to a long history of late, over-budget, under-delivering mega-projects that follow the waterfall methodology. Waterfall defenders often point to agile’s accountability problems in regulated, audit-heavy environments where “iterating toward a solution” may conflict with procurement law.
Both sides have legitimate perspectives.
The research at the center of this series found that the most effective government digital programs have moved away from this argument, and toward a hybrid approach that blends waterfall’s structure with agile’s adaptability. One government CIO gave it a name that stuck: “wagile.”
WHY WATERFALL PERSISTS IN GOVERNMENT
Waterfall’s sequential, phase-by-phase approach has dominated government technology projects for reasons that still apply. Structured documentation supports audit and compliance requirements. Detailed planning creates clear deliverables that survive staff turnover -- a constant in public sector programs where political oversight changes every two to four years.
Waterfall’s predictability also makes it compatible with how government tends to procure large-scale technology projects. Fixed-scope contracts with defined deliverables and clear timelines align naturally with waterfall artifacts.
But using the waterfall approach assumes that an agency can know, upfront, everything the system needs to do. In digital transformation -- where technologies evolve mid-project, policy shifts, citizen needs change, and cybersecurity threats emerge in real time -- that assumption increasingly fails.
WHY AGILE STRUGGLES IN GOVERNMENT
Agile’s iterative model naturally fits digital transformation’s complexity. Experimental development advances genuinely innovative public services. Agile surfaces problems early, when they are less costly to fix. But agile’s advantages in commercial technology development have been seen as liabilities in government contexts. Reduced emphasis on upfront documentation can conflict with audit requirements. Flexible scope can create budget unpredictability that do not align with longstanding procurement frameworks. As one government CIO interviewed for this research stated, “We cannot do agile as it was intended, but are doing it as best as possible within government processes.”
WHAT WAGILE ACTUALLY LOOKS LIKE
The “wagile” approach does not split the difference between agile and waterfall, but rather places them in sequences. Different phases of a government technology project have different requirements, and the methodology should match the phase.
Early development phases can focus on agile principles: iterative sprints, stakeholder feedback cycles, functional increments delivered over time.
THE DEEPER POINT ABOUT METHODOLOGY
The wagile insight reflects a broader principle: government digital programs consistently fail when they apply a single framework to a heterogeneous program. Project methodology needs to be as contextually intelligent as every other design decision.
Wagile ultimately offers a methodology that can serve the mission -- not the other way around. Organizations using agile and waterfall at appropriate points can achieve better results over time.
--- KEY TAKEAWAYS ---
-> Pure agile conflicts with.
-> “Wagile” -- agile principles operating within waterfall governance structures – reflects a practical methodology to address government’s audit, procurement, and accountability requirements as well as digital complexity.
-> The key is sequencing: agile for development and iteration, waterfall for scale operations. Methodology should follow phase and context, not applied uniformly across an entire program.
-> This results in both accountability and adaptability -- not a trade-off.