Civic Innovations

Agile software development was always solving two problems at once, though we’ve not always talked about them separately. One problem that Agile helped solve was a human problem, a problem with people. The other problem that Agile helped solve was an engineering problem. For a long time this distinction didn’t matter all that much, but AI is now poised to make that distinction matter a great deal.

The human problem Agile helps solve is about understanding: you don’t know what you need until you start building it. Requirements often change. Users can’t always articulate what they want until they see for themselves what they don’t want. The only reliable way to surface that knowledge is to put working software in front of real people, watch what happens, and then adjust. That “build, show, learn, repeat” loop is the main reason Agile exists, and it doesn’t have anything to do with how fast you can generate code.

The engineering problem is different. Large software systems built in long sequential phases fail at a very predictable rate. Errors get compounded. Integration problems stay hidden until the worst possible moment. By the time anyone sees working software, bad decisions are really, really expensive to reverse. Breaking work into small, short increments reduces that risk. It keeps the codebase in a releasable state. It limits the blast radius of any single mistake. That problem is fundamentally about managing the cost and complexity of writing code by hand.

AI coding tools are reshaping the second problem faster than most agile practitioners want to admit. When a working prototype can be generated in hours rather than weeks, the risk calculus that made two-week sprints and velocity tracking essential looks very different. The scaffolding agile built around engineering complexity starts to look like process overhead designed for a world that is quickly disappearing.

But the first problem – the human problem – is largely untouched, and in government it may actually be getting harder, not easier.

Some Things Still Take Time

The knowledge that government software needs to reflect doesn’t live in a repository. It lives in the heads of the government workers – caseworkers, clerks, and frontline staff who know how a process actually works as opposed to how it’s documented. Getting that knowledge into a system still requires sustained human engagement. No AI coding tool changes that, or – at least not yet – makes it significantly easier.

Stakeholder alignment in government takes time for reasons that have nothing to do with technical complexity. Multiple agencies, competing political interests, legal constraints, and accountability requirements all shape what a system must ultimately do. The organizational and political work of building consensus around requirements isn’t something you can generate faster.

And government policy can change mid-flight. Regulations get revised. Administrations turn over. Court decisions alter what a system must do. The value of being able to adapt quickly doesn’t diminish because the code itself is cheaper to write.

The Costume Comes Off

A great LinkedIn post circulating recently made an observation about product managers that applies with equal force to agile practitioners in government: AI isn’t eliminating the job. It’s revealing what the job was actually supposed to be all along.

A lot of what passed for agile practice in government – writing user stories, maintaining backlogs, running standups, producing sprint reports – was coordination and artifact production. It was administration wearing a methodology costume. AI will commoditize most of that work quickly. What remains is the part that was always harder: judgment about which problem is worth solving, the ability to say no with a clear rationale, and a deep enough understanding of users to spot what they need before they can fully articulate it.

That’s the part of the problem pair that government has historically underinvested in. And the structural barriers I’ve been writing about for more than a decade – procurement, budgeting, civil service constraints – don’t inhibit the administrative layer of agile practice. They inhibit the strategic layer. They make it hard to act on good judgment even when you have it.

The New Asymmetry

What’s emerging now is an asymmetry that could produce its own form of dysfunction. The technical barriers to building custom software are falling fast. AI coding tools are lowering the cost and risk of custom development in ways that are beginning to challenge the decade-long default toward commercial off-the-shelf software. The build-versus-buy calculus that drove so many government technology decisions is due for a reexamination.

But the processes for deciding what to build, contracting for it, and staffing it haven’t changed. An agency could theoretically commission custom software quickly and cheaply, but the procurement cycle that governs the decision to do so still moves at the same pace it always has. The gap between what’s technically possible and what government processes can accommodate is widening fast.

Requiem for the 2-week Sprint

Agile in government needs to be rebuilt around the problem it was always better suited to solve. Less emphasis on sprint velocity and delivery cadence. More emphasis on discovery: the sustained, disciplined work of understanding what users actually need, what existing systems actually do, and what institutional knowledge is embedded in processes that predate any software system by decades.

This work isn’t glamorous and it doesn’t fit neatly into two-week cycles. But it’s the work that determines whether the software that eventually gets built solves the right problem. In a world where generating code is getting cheaper by the month, that determination is where nearly all the value will live.

The Agile movement was an appropriate response to the failings of waterfall development. Waterfall front-loads all the decisions and defers all the learning, which is exactly backwards from how complex software projects should work. Getting working software in front of real users quickly matters more than documents and promises. Those learnings still apply.

What no longer does is the idea that managing the engineering complexity of human-generated code is the central challenge that Agile needs to solve. It simply isn’t anymore. The central challenge that Agile endeavored to address – understanding what to build and for whom – was always the harder part of the equation. We just had enough other problems to distract us from noticing.

It’s the end of Agile as we know it.