Agile was a mistake in service design... Or was it?

By Astrid Van Waveren, Head of Insight & UX, GAIN Experience

At SD in Gov back in 2025, we asked hundreds of public-sector service designers to share their “hot takes.” The one that got the most votes? 

“Agile was a mistake in service design.” 

Strong words. But they clearly hit a nerve. 

If you’ve worked in or around government digital teams, you’ve probably felt this tension first-hand. Agile has become the default way of delivering digital services. But as more organisations “go Agile,” the cracks are starting to show. 

So, was Agile actually a mistake? Or have we just lost our ability to utilise the agile way of working effectively? Let’s unpack both sides of the argument and explore what might come next for service design in the public sector. 

What we mean when we say “agile” 

When people talk about Agile, they usually mean the sprint-based, backlog-driven approach used in product teams: small iterations, continuous feedback, “fail fast, learn faster.” 

It’s great in theory. But service design in the public sector is different. You’re dealing with policy, regulation, funding cycles, legacy systems, and high accountability. You’re not just building features, you’re designing entire services that span departments, user journeys, and organisational boundaries. 

That’s where things get complicated. 

The case for “agile was a mistake” 

Let’s start with why so many practitioners feel frustrated with Agile in service design. 

1. It skips the strategic thinking 

Agile encourages teams to start small, deliver something fast, and iterate. But in government, if you don’t spend enough time defining the problem, you risk iterating in the wrong direction. 

The National Audit Office has warned that many large digital programmes fail because they skip deep planning (things like data dependencies, governance, and integration points) before diving into delivery. Without that foundation, Agile teams often find themselves spinning their wheels. 

2. It doesn’t fit public-sector rhythms 

Agile runs on two-week sprints. Government runs on annual budgets and multi-year plans. Those cycles rarely align. 

As McKinsey points out, public organisations struggle when Agile’s flexible delivery model meets rigid funding structures. You can’t just “pivot” mid-year when your budget and targets are locked in. 

3. Procurement can’t keep up 

Public-sector procurement rules often demand fixed scope and defined deliverables before a project starts. That’s the opposite of Agile’s “emergent” approach. 

In the U.S. federal context, fixed contracts and compliance-heavy oversight have made it nearly impossible to iterate quickly, the same story many UK teams will recognise. 

4. Fear of failure kills experimentation 

Agile thrives on experimentation. But in government, failure is political. A missed sprint goal might make headlines. So, teams naturally play it safe. 

Research on Agile adoption in the public sector shows that fear of risk, cultural inertia, and unclear accountability make it hard to truly embrace the “fail fast” mindset. 

5. The system view gets lost 

When you’re deep in sprint cycles, it’s easy to focus on the next story in the backlog and forget the whole service ecosystem. 

Service designers often talk about “zooming out” to see how users experience services end-to-end. But Agile’s rhythm can squeeze out that reflection time. The result? Local optimisation at the expense of system-wide improvement. 

The case against “agile was a mistake” 

Now for the other side, the reason so many teams still swear by Agile. 

1. It helps you adapt in uncertainty 

If the last few years have taught us anything, it’s that public services must adapt fast, from pandemic responses to cost-of-living pressures. 

Agile gives you a way to learn quickly and respond to change instead of being locked into multi-year delivery plans. That’s why Deloitte and others argue that governments can’t afford not to be Agile. 

2. You can deliver value sooner 

Rather than waiting 18 months to launch a “finished” service, Agile lets you release usable features early, gather real feedback, and improve continuously. 

That means less wasted effort and more visible progress for users and stakeholders. 

3. It brings users into the loop 

Frequent testing and iteration mean you’re constantly checking whether the service works for real people. That’s at the heart of service design. Agile, when done right, makes co-creation a natural part of delivery. 

4. Hybrid models work best 

The truth is, few government teams run “pure Agile.” Most use hybrid approaches combining upfront discovery and strategy with iterative delivery. 

Think of it less as following a manifesto, and more as choosing the right tool for the job. Agile doesn’t have to replace service design, it can complement it. 

5. Agile has proven itself in government 

There are examples where Agile worked. The Opportunity Project in the U.S. used 12–14-week sprints to co-create data tools across government, industry, and communities. It showed that, with the right guardrails, Agile can drive collaboration and innovation in the public sector. 

So, was agile a mistake? 

Not exactly. 

Agile wasn’t the mistake, how we applied it was. 

Public-sector teams often imported Agile wholesale from the tech world, without adapting it to their own constraints: governance, funding, procurement, policy alignment. 

Or created a delivery model that tried to use agile principles within a rigid ecosystem, a hybrid model that often resulted in the confused and inefficient ways of working.  

The result? Teams delivering features in isolation while the bigger system stayed unchanged. 

When Agile ignores the realities of the public sector, it’s no surprise people call it a mistake. But when it’s adapted, when it coexists with strategy, governance, and user insight, it can still deliver real value. 

What’s next: Adaptive service design 

Maybe it’s time to move beyond the “Agile vs. Waterfall” debate altogether. 

Instead of asking, “Should we use Agile?” ask: 

“How can we make our delivery more adaptive, strategic, and human-centred?” 

That might mean: 

• Starting with service maps, not just backlogs 

• Aligning funding cycles with delivery rhythms 

• Building safe-to-fail pilots to reduce political risk 

• Giving designers time to zoom out, not just sprint in 

Because the problem isn’t iteration. The problem is when iteration loses sight of the system. 

Final thoughts 

Whether you love or loathe Agile, the debate is valuable. It forces us to reflect on what’s actually working and what’s holding us back. 

We help public-sector organisations design services that are both strategic and adaptive, blending the best of service design thinking and iterative delivery. 

If you’re wrestling with how to make Agile work in your context, or wondering whether to leave it behind entirely, we can help you find the right balance. Get in touch.

FAQs: Agile and service design 

Q: What’s the main difference between Agile and service design? Agile focuses on how to build things iteratively. Service design focuses on why and what to build: aligning policy, people, and operations. They’re complementary, but not interchangeable. 

Q: Is Agile too risky for government? Not if it’s adapted. The key is creating governance and procurement models that support iteration without losing accountability. 

Q: Should public services just go back to Waterfall? No. Waterfall is too rigid for today’s pace of change. The answer isn’t “go back”, it’s “evolve forward.” 

Q: What’s the best approach for public-sector projects? A hybrid model works best: combine strategic discovery and user research with agile delivery and continuous learning.