Agile in the Public Sector: Why It's Harder Than the Books Say

The first time I tried to run a proper sprint review with a public-sector client, the product owner sent me a seventeen-page approval chain I needed to complete before any stakeholder could see a working prototype. We were two weeks into the project. The sprint was two weeks long. The approval chain would take three.

That is not an edge case. That is the environment. And if you walk into a government digital project expecting agile to work the way it does in a funded startup or a product-led tech company, you will spend a lot of time confused and a lot of the client's money going nowhere.

I have delivered digital projects inside public institutions across more than fifteen countries. I have also built and shipped products in the private sector where we moved fast and broke things on purpose. The gap between those two worlds is real — but it is not unbridgeable. What it requires is honesty about where agile actually fits, and where you need to adapt or abandon the textbook version entirely.

What makes public-sector delivery structurally different

Agile assumes a few things that public institutions often cannot provide. It assumes a product owner with genuine decision-making authority. It assumes the ability to release incrementally to real users. It assumes that changing direction mid-project is acceptable. In most public administrations, none of those assumptions hold cleanly.

Budget cycles in government are annual, sometimes multi-annual. Scope is frequently locked at contract signature because procurement law requires it. The "product owner" is often a committee, or a civil servant who has accountability without authority, or both at once. And releasing to citizens before a full legal and accessibility review is not a shortcut — it is a liability.

This does not mean agile is wrong for government. It means that the version of agile you apply needs to be honest about these constraints rather than pretending they do not exist. The PM²-Agile framework from the European Commission is one of the few methodologies that actually tries to do this: it layers iterative delivery practices on top of a governance structure that keeps sponsors, legal teams, and audit trails intact. It is not perfect, but it is more realistic than telling a directorate-general to "just trust the process and ship every two weeks."

Where agile genuinely helps — and where it creates chaos

In my experience, agile practices deliver real value in three specific areas inside public-sector projects.

First, discovery and requirements. Government digital projects almost always start with requirements written by people who are not the end users. Running structured discovery sprints — user interviews, journey mapping, prototype testing — before any development begins consistently surfaces problems that would otherwise be baked into a specification document and then built faithfully into the wrong product. This part of agile saves money. It is also the part that clients are most resistant to funding, because it does not look like "building" anything.

Second, integration and technical risk. Large public-sector systems connect to legacy infrastructure that nobody fully understands. Running short technical spikes to validate assumptions about APIs, data formats, and authentication protocols before committing to an architecture is exactly what agile is for. I have seen projects lose six months because an integration that looked straightforward on a diagram turned out to require a procurement process for a middleware component nobody had budgeted for. A two-week spike would have found that in week three of the project instead of month nine.

Third, internal tooling and back-office systems. When the users are civil servants rather than citizens, you have more control over rollout, feedback loops are shorter, and the legal exposure of an imperfect release is lower. This is where iterative delivery closest to the textbook version actually works in government.

Where agile creates chaos is in citizen-facing services with hard regulatory deadlines, in projects that cross multiple agencies with different governance structures, and in any context where the contract is fixed-price fixed-scope. Trying to run sprints inside a fixed-price contract without renegotiating the commercial model is not agile. It is just waterfall with stand-ups.

The product owner problem is the hardest one to solve

Every agile methodology places enormous weight on the product owner role. In Scrum, the product owner is the single person accountable for the backlog, the priorities, and the value of what gets built. In public administrations, that role is almost never structured that way.

What you usually find is a project sponsor who has political accountability but no time, a technical lead who has context but no authority to make business decisions, and a steering committee that meets quarterly and communicates through formal minutes. None of these people can play the product owner role as described in the Scrum Guide.

The practical solution I have used is to separate the role explicitly. You need someone with enough seniority to unblock decisions — call them the senior responsible owner, the term PM² uses — and someone with enough operational knowledge to be present in the day-to-day — a business analyst or domain expert who can act as a proxy product owner for sprint ceremonies. The senior person reviews and approves at defined milestones. The proxy person is available continuously. This is not ideal agile, but it is functional agile inside a real institution.

What does not work is pretending the problem does not exist, or trying to convince a director-general that they need to attend sprint reviews. They will not, and the project will stall every time a decision needs escalation.

Change management is the delivery, not an afterthought

I wrote separately about why AI projects fail at change management rather than technology. The same logic applies to agile adoption in government, and it applies even harder.

When you introduce iterative delivery into an organisation that has run waterfall programmes for thirty years, you are not just changing a process. You are changing how people understand accountability, how they report progress to ministers or commissioners, how they handle audit requests, and how they talk to procurement officers who expect a signed-off specification. That is a significant organisational shift, and it does not happen because you ran a one-day Scrum training.

The projects I have seen succeed at agile adoption in public institutions all had a few things in common. They had a senior champion who understood and publicly defended the approach. They invested in explaining the new process to legal, finance, and audit teams before problems arose, not after. They kept formal documentation — decision logs, milestone reports, risk registers — even when it felt like overhead, because those artefacts are what protect the project when scrutiny comes. And they were honest with stakeholders about what "working software every two weeks" actually means in a context where releases require accessibility testing, security review, and translation into multiple official languages.

Agile in government is slower than agile in a startup. That is not a failure of agile. It is an accurate reflection of the environment. The teams that accept that and plan for it deliver. The teams that fight it spend their energy on the wrong battle.

What I would do differently

If I were starting a public-sector digital project today, I would do three things from day one that I learned the hard way.

1. Negotiate the governance model before the backlog. Agree in writing how decisions get made, who has authority at each level, and what the escalation path looks like. This is not bureaucracy. It is the thing that keeps sprints moving when the inevitable conflict arises.
2. Run a two-week discovery sprint before committing to any delivery timeline. Use it to validate the integration assumptions, map the real user journeys, and identify the regulatory constraints that will affect release cadence. Every week you invest here saves a month later.
3. Set expectations about velocity in writing. Public-sector sprints are not startup sprints. Accessibility reviews, translation, legal sign-off, and procurement dependencies all affect throughput. A sprint that delivers one reviewed, approved, deployable feature is a successful sprint. Measure accordingly.

Agile works in government. But it works on government's terms, not the Scrum Guide's. The sooner you accept that, the sooner you start actually delivering.