Agile in Government

When I first wrote this post in 2020, the question was still "can agile work in government?" Six years later, that question is settled — iterative delivery is now standard practice across federal and state modernization programs. The 2026 questions are harder and more interesting: how do you keep agile honest under audit, how do you buy it, and what happens when AI enters the delivery model?

Having spent much of my career leading large public-sector and enterprise modernization programs, I've watched this evolution from inside the steering committees. This is a ground-up refresh of my original post, keeping what held true and updating what the last six years have taught us.

What changed between 2020 and 2026

Three shifts define the current landscape:

• Agile stopped being an experiment. Modular contracting and iterative delivery are now written into federal and state IT procurement guidance rather than argued for project by project. The debate moved from methodology to execution quality.
• AI arrived faster than the acquisition playbook. Federal agencies more than doubled their AI use between 2023 and 2024, with roughly $1.7 billion appropriated for AI efforts across government — and a recent GAO review of AI acquisitions found agencies still aren't systematically collecting lessons learned from them. Government is buying 2026 technology with processes that predate it.
• Citizens' expectations kept rising. The bar is no longer "the portal works." It's the experience people get from the best consumer products, delivered by agencies under flat budgets and intense scrutiny.

Procurement grew up — mostly

In 2020 I argued that contracts should emphasize outcomes over rigid requirements. That's now mainstream: outcome-based agreements, modular awards sized to quarters rather than years, and vendor checkpoints tied to working software are common in well-run programs.

The unsolved frontier is buying AI. GAO's review of federal AI acquisitions surfaced six recurring challenges, and they'll be familiar to anyone doing this work at the state level too: access to genuine subject-matter expertise, protecting government data and IP rights, acquisition timelines that outlast the technology cycle, defining requirements for systems that learn and change, early and continuous testing, and pricing models nobody fully trusts yet. The practical answer inside programs I've seen succeed:

• Buy AI capability as a service with exit ramps, not as a monolithic system — evaluation gates every quarter, with the contractual right to walk away.
• Write data rights and model behavior expectations into the contract up front; retrofitting them mid-program is nearly impossible.
• Treat continuous evaluation as a deliverable — the vendor ships evidence that the AI still behaves, not just features.

Documentation and audit: from "living documentation" to continuous compliance

My 2020 advice was to maintain living documentation in shared repositories rather than end-of-phase binders. That aged well, and the leading edge has moved further: compliance evidence generated as a byproduct of delivery itself. Decision logs kept in the same tools as the backlog, architecture records versioned alongside code, and security authorization treated as a continuous process rather than a one-time gate. When the auditors arrive — and in government, they always arrive — the programs that thrive are the ones where producing evidence takes hours, not a quarter of rework.

One thing I tell every public-sector delivery team: auditability is a feature of your operating model, not a tax on it. Teams that fight documentation lose credibility with oversight bodies, and credibility is the real currency of multi-year funding.

Budgets and legislatures still think in years. Deliver in quarters anyway.

Legislative funding cycles haven't changed: appropriations still want multi-year certainty that agile can't honestly promise. What's matured is the translation layer between the two:

• A stable vision and outcome roadmap for the legislature — the "what and why" that survives the whole appropriation.
• Incremental scope commitments underneath it — the "how and when" reassessed quarterly against actual delivery data.
• Historical velocity as the estimation basis — after a decade of public-sector agile, agencies finally have their own delivery data; the mature ones use it instead of vendor optimism.

Programs get in trouble when they let the funding narrative and the delivery reality drift apart. The program leader's job is to keep those two stories reconciled every single quarter — that's engagement management as much as project management.

The new chapter: AI inside the delivery model

The biggest addition since 2020 isn't a refinement of agile practice — it's that AI is now both the thing being delivered and part of how programs deliver. Two consequences matter for government:

First, AI programs need agile more than traditional IT ever did. A system that learns can't be specified once and accepted three years later. Iterative delivery, early testing, and continuous evaluation aren't preferences for AI acquisitions — they're the only honest way to buy something whose behavior evolves. GAO's finding that agencies struggle with "requirements definition and early testing" for AI is really a finding that waterfall habits and AI don't mix.

Second, AI-assisted delivery raises the governance bar. As agencies and their vendors adopt AI agents for status aggregation, dependency monitoring, and risk detection, public-sector programs need what I call decision-boundary governance: explicit rules for what automation may do unassisted, what requires human approval, and how every automated action stays traceable. In a sector where accountability to the public is the whole point, "the system flagged it and a named human decided" must be the design pattern — and that traceability requirement is one government is well positioned to lead on, because it has demanded audit trails for decades.

Culture: what actually moves agencies

My 2020 advice — start with a compelling case for change, pilot small, scale gradually — still stands, but I'd sharpen it with what I've seen work since:

• Product over project. The agencies making real progress fund stable product teams that own a service long-term, instead of re-forming a new project (and relearning everything) with each appropriation.
• Executive sponsors who show up. Not on the charter — in the room. Public-sector transformations survive leadership transitions only when the sponsorship is institutional, not personal.
• Wins measured in citizen outcomes. Cycle time and velocity convince practitioners; reduced call-center wait times and faster benefit determinations convince legislatures.
• Vendors as accountable partners. The old fixed-scope adversarial posture produces exactly the outcomes it always did. Outcome-based contracts only work when the agency brings real product ownership to the table — accountability has to be mutual.

The 2026 verdict

Can agile be adopted in the public sector? In 2020 my answer was "absolutely, with tailoring." In 2026 the answer is: it already has been — unevenly, imperfectly, and irreversibly. The differentiator now isn't whether an agency runs sprints; it's whether its procurement, funding, audit, and governance machinery have evolved to match — and whether it can extend that same iterative discipline to the AI systems it is now buying at speed.

The public sector taught me some of the hardest and most valuable lessons of my delivery career: that constraints are design inputs, that trust with oversight bodies is earned in increments, and that the mission — services that citizens depend on — makes the difficulty worth it. Agile didn't remove those constraints. It gave us a way to deliver inside them, honestly, one increment at a time.