Can you do agile policy work?

And why even bother trying?

Citizens Advice is a special place to do policy work for lots of reasons.

One is that our policy teams sit alongside our digital teams, which is a great opportunity to share ideas between the two.

In the last few years, one thing we’ve explored is how the principles of agile software development could be applied to policy work.

While I don’t think we’ve cracked this, we’ve learned a lot along the way, so I thought I’d share some reflections.

A generic example of a kanban board in Trello

Why try?

Why bother applying the principles of agile software development to an arena as different as policy influencing?

Because a lot of the rationale behind agile software development also applies to policy work.

• The environment changes really fast, so it’s risky to spend ages planning up front — you might get left behind. In software, that’s because technology might move on; in policy, it’s because politics might move on.
• It’s hard to know how something will land before you test it in the real world. In the case of software, that’s true of a new feature or piece of content, while in the case of policy, it’s true of an argument or idea.
• It’s good to release value early if you can. The sooner you get your ideas out there, into the world, the sooner they’re adding value (and generating feedback). So once your ideas have cleared a certain quality threshold, it’s worth sharing them rather than refining them too much.
• The people doing policy research often know more about it than their senior colleagues — and they often also feel a deeper connection to the work. Hierarchical decision-making can also be too slow, missing opportunities, so there’s a strong case for autonomy here too.
• The disciplines involved in policy work add more value when they’re combined — robust research, for example, plus press work, plus data analysis. And this needs ongoing collaboration, not baton-passing.

What have we done?

For all these reasons, we’ve been exploring whether agile principles — which we of course apply in our DDaT teams — can add value to our policy work.

To be specific, we have:

• Moved away from siloed / discipline-based policy teams to form multi-disciplinary teams around a policy outcome. This meant bringing together disciplines like press, policy research, data analysis, and public affairs, into a single team seeking to achieve a policy goal.
• Pushed ourselves to be more outcome-centric in our policy work, so that we plan work less on the basis of ‘projects’ or outputs and more on the basis of an outcome we want to achieve.
• Given our teams lots of autonomy to pursue these outcomes, choosing their tactics as they go. The role of leaders in these debates has been to stress-test and challenge, not to sign-off or instruct. We’ve setup a mechanism we call ‘challenge panels’ for this purpose.
• Encouraged iteration — we try to test and then refine our arguments and ideas, rather than sticking rigidly to a plan we’ve decided up front.

A lot of this has worked really well. It’s made us much more effective, outcomes-focused, and data-driven, and we now collaborate in a much deeper way. As a result, we’ve helped to improve many areas of government policy, particularly during the pandemic, filling gaps in protections, securing additional support for marginalised groups, and standing up for consumers.

There are also a few things we have’t yet got right.

On reflection, we’ve sometimes struggled to uphold the agile principle about releasing value early and often.

By becoming more outcome-focused, at times we’ve paradoxically become more inward-looking. We’ve sometimes spent too long talking about our tactics or framing, and not enough time facing outward, writing or speaking about our ideas in public.

Sometimes we’ve also gone through several iterations of an idea or an output without saying anything publicly, while revising it in private — a behaviour that again cuts against the agile principle of releasing value early and often.

A journey to maturity

Reflecting on our experience, I don’t think we should be too hard on ourselves. One thing that’s tricky about applying agile principles in a new context is that there isn’t a mature set of practices and processes to draw on.

In policy work, one particular challenge is that there isn’t yet a clear and well-defined set of roles within a multidisciplinary team.

If you think about a software product team, the roles are pretty well-established. There are lots of arguments about the nuances, of course, but in general people know what a product owner does, and it’s fairly clear how a developer, UX designer, or delivery manager fit into the team.

On top of this, in software development, there are well-developed ways to prioritise work and to resolve conflicts, and a whole plethora of tools and frameworks, from kanban boards to lean UX, to draw on.

Also, the product itself — and what it means to ship a new feature or improvement — is relatively clearcut. So when you talk about the early release of value, people know roughly what you mean.*

In policy work, all of this is less well-developed.

The roles aren’t nearly so well defined — or at least their interaction within an agile context isn’t yet defined.

I don’t mean by this that the roles themselves are confusing. We all know what a press officer is. But what specific role does a press officer play within an agile team? Are they the equivalent to a developer, so that the press release is the equivalent to shipping a new feature? Sort of, but not quite — you can’t just replicate the model used in digital work.

Likewise, there aren’t established frameworks, and the ‘product’ itself — a policy idea, for example, or an argument — is a little harder to pin down.

All of which is to say: I think there’s definitely something in this, and I think we’re right to keep trying, but it’s tricky. As with all new ways of working, we need to keep learning and maturing — and sharing as we go.

I’d love to know if other organisations have tried something similar, and what you’ve learned along the way.

If you’re interested in how we adapt to a digital economy, my new book — End State: 9 ways society is broken — and how we can fix it — is out now and available here.

*. I know product/software people will protest here, and say all these things are still fiercely contested. But my point is just that they’re relatively more settled/established than they are in the context of agile policy work.