The limits of agile - can we apply it to policy making - Policy Lab.

pdf
Saved to Dropbox • 30 May 2020 16:06

GOV.UK

Blog

Policy Lab
Search blog

Organisations: Civil Service

Policy Lab
The limits of agile - can we Policy Lab is bringing new policy
apply it to policy making? tools and techniques to the UK
Government.

We are a creative space where policy

Lisa Ollerhead, 27 January 2015 - Uncategorized
teams can develop the knowledge
On Saturday, I went to UK Govcamp 2015, an all-day event where 200 people and skills to develop policy in a more
interested in innovation, data and digital in the public sector (among other open, data-driven, digital and user-
things) get together to talk about - well, whatever they want to talk about on centred way.
the day, such being the unconference structure. It was my first one and I
We make policy making more open.
went along slightly nervous but hoping to learn more about some of the big
This is in support of the vision for A
ideas that are occupying us at the moment on the OPM team, like
Brilliant Civil Service.
government as a platform, helping reformers in government network and
support each other, and agile methodology for policy making. To commission us, email:
policylab@cabinetoffice.gov.uk

Agile policy making and implementation is a popular notion in the civil service
About Policy Lab
at the moment. We’re really keen to include it in our open policy toolkit. Lots
of people are talking about it, but when I started looking behind that, it About Open Policy Making
seemed that not many people are actually doing it. (Am I wrong? If you’re
doing it email me and let me pick your brains!) So it looks like that what we’re Open Policy Making Toolkit
working on might be the first attempt to put in place some cross-government
ideas and guidance on how agile for policy making actually works. Bit scary,
that. Especially when we're not even sure how useful or appropriate it is.
That's why we're throwing this question out for mass consideration as early as Follow us
possible: should we try to adapt agile for policy making? If so, can it be done?
If so, how? Follow Policy Lab on Twitter

View the Policy Lab slideshare

I’ve found a small group of people in government who are interested in agile
for policy making who have already started developing material of their own
and will be involved in this process of figuring out if/how agile for policy
Sign up and manage
making works and how to tell people to do it - people like DWP Digital updates
Academy and the MoJ digital capability team (and of course Policy Lab -
Email Atom
watch this space for an upcoming piece on some agile policy making they did
last week). Govcamp put me in touch with several more, including external
people like Catherine Howe who has been actually doing this on NHS Citizen.
Even more usefully for me, I went to a session on ‘why agile sucks’ where Blogs
Harry Harrold pointed out that a lot of the things people dislike about agile
are just the window dressing: to understand it, just go back to the original Examples and findings
manifesto.
Thought Pieces

Policy Lab
Good advice, I thought, when trying to think through for myself how agile can
be applied to a very different discipline. The agile manifesto was created in Skills, tools and techniques
2001 by a group of developers who wanted to codify the agile methodology
into the elements that were really important. They came up with four values Start the week
and twelve principles for how to develop software using agile. The main point
Events
of this is that agile is a mindset, a culture, around delivering small steps
forward fast and often: that’s what we need to bring into policy making, not
just overlaying a Trello board and weekly scrums onto a traditional policy
process and calling it agile.

After Govcamp, I’ve had a think about whether and how these values and
principles might translate to the policy context. This is what I came up with.

Values:

– individuals and interactions over processes and tools

– viable solutions that benefit citizens over endless papers
– ministerial input and user research over bureaucracy
– responding to change over following a plan

Principles:

Our highest priority is to satisfy the minister through early and continuous
delivery of viable policy solutions that benefit the citizen.

Welcome new information, even late in development. Agile processes

harness change for advantage during policy implementation.

Deliver policy milestones frequently, from a couple of weeks to a couple of

months, with a preference to the shorter timescale.

Policy makers and service delivery must work together regularly throughout
the project.

Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and

within a policy team is face-to-face conversation.

The testing of solutions is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, policy

makers and users should be able to maintain a constant pace indefinitely.

Continuous attention to evidence bases and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

At regular intervals, the team reflects on how to become more effective and
tunes and adjusts its behavior accordingly.

- values and principles borrowed and/or adapted from the Agile Manifesto

The big challenge to me so far is the deliverable: the equivalent of 'working

software' upon which progress can be clearly seen. The range of activities
that constitute policy making may mean each agile policy team needs to
define this - and therefore appropriate iterated 'milestones' - for each project
or piece of work. What the different roles are and how they interact is another
challenge.

Now over to you. What do you think? What are the limits of agile when
applying it to a different environment? Can agile be adapted to policy
making? Have I horribly misunderstood and mangled a noble methodology? Is
this a fair rendition of agile to the policy world? More importantly: is this a
useful starting point to think about helping policy makers use agile? Let me
know below, by email, or on Twitter.

Tags: OPM team

Open these: links for open policy Testing policy sprints

makers (week 28)

Share this page

Twitter Facebook LinkedIn Email

12 comments
wfmtj2395u03jr on 27 January 2015

'Our highest priority is to satisfy the minister' is your number one objective
and the biggest issue. I know it is the reality but it goes against the entire
principle of meeting user need, which is why government policy can never be
truly 'agile'.
Link to this comment

Reply

Lisa Ollerhead on 28 January 2015

That's really interesting, thank you. Trying to translate the roles between
software development and policy making was one of the things I found
quite tricky. I think GDS shows how both ministers and user needs can be
satisfied - the drive is towards 'a service that delivers x outcome' and the
user needs are looked at when figuring out what that should actually look
like. But yes, ultimately civil servants are responsible for delivering what
is asked of them by the government of the day.
Link to this comment

Reply
 Jon Wiltshire on 02 February 2015

(Just saw this, I've been on holiday).

Awesome blog! Awesome because I think the idea of applying an agile

ethos to policy making is on the minds of a large number of people that
I've spoken with that are working in and around digital projects BUT
within a non-agile setting (i.e. the traditional civil service). Why? In my
(humble) experience agile teams seem productive, innovative, motivated
and generally happier than non-agile teams.

A few thoughts:

1. There shouldn't be a conflict in thinking about ministers and citizens as

users. The difference between being 'user-focussed' not 'user-led' is
something to bear in mind. Software has different users with different
needs, so why can't policy?
2. In my (again, humble) experience, agile teams are usually mutli-
disciplinary. So I think you're right to be talking about 'agile policy
making' and not 'agile policy makers'. Agile policy making should,
surely?, include a team that comprises or is representative of Ministers,
policy wonks, researchers, legislative people, press and comms,
operational delivery people, front line staff, and citizens at various stages
of iteration.
3. Strongly agree with Nupur that a) the huge advantage to an agile ethos
will be building motivation in self-directed teams that are trusted to
deliver and b) it'll be hard, but it's surely alright to rely on feedback
proxies for long-term change (it's what policy people do already).

A question: are any other digitally-savvy governments doing this stuff?

Korea? New Zealand? Anyone know? Has Code for America or anyone
similar explored this stuff?

Very interesting. Let's talk. I'm on @jonwiltshire. Good luck!

Link to this comment

Reply

Greg Smith on 28 January 2015

Interesting post. I've been managing policy implementation projects for most
of the last 7 years and as I learned about agile I realised it had a lot of
commonality with some of the methods I'd developed, mainly through painful
trial and error, and adaptations of traditional project management. things like
embracing change and prototyping (in the abstract) translate, but some agile
elements like flexing scope or an mvp when you're implementing legislation
are less transferable. Happy to discuss further. I'm @everysandwich on
twitter.
Link to this comment

Reply

Lisa Ollerhead on 28 January 2015

Hi Greg, thanks for responding! It's great to hear from someone who has
been actually living agile on projects (as opposed to sitting on their sofa
 just thinking about principles, like, er, me). I'll drop you an email, it would
be great to have a chat about this and get you involved in the wider
toolkit development process.
Link to this comment

Reply

Nupur Takwale on 28 January 2015

Great blog!

I think that in theory at least, agile should apply very effectively to certain
policy areas. After all, agile is supposed to be best suited to conditions of high
complexity and/or uncertainty (and superior to a waterfall approach in those
conditions). Such conditions are a fairly reasonable representation of the
context of social policy. Building up from user research and user needs can
probably also be squared with the need to 'satisfy the Minister', in terms of
allowing policy-makers the chance to present options backed up by real
prototypes in briefings and submissions...

This is also the consideration that agile ways of working have the potential to
increase productivity, because they rest on self-organising teams and
intrinsic motivation. That's something relevant to policy, operational and
corporate teams throughout the Civil Service.

I think you're right that the biggest challenge is the 'deliverable' - unlike
digital products, you can't necessarily get feedback from end users at the end
of a two week sprint, especially if what the policy is ultimately about is
causing some kind of long-term behavioural change. However I'm aware that
there are methodologies that do deal with this, by substituting perfect
feedback for proxies and predictors of what the result of the policy would be.

In all, this is an area ripe for investigation. At Ministry of Justice Digital

Services, we're trialling an agile transformation project with a Legal Aid
Agency team - so we'll keep you posted! Incidentally, digital/open policy
making teams across government who aren't necessarily making digital
products (such as digital capability in MOJ, and also the team at the Foreign
Office, as well as of course, yourselves) are experimenting with working in an
agile way themselves. How those are going might be useful case studies.
Link to this comment

Reply

Lisa Ollerhead on 08 February 2015

Hi Nupur, thanks for this comprehensive comment! The substitution of

proxies and predictors sound really interesting - following Lab's
experiments with policy sprints we've been having a bit of a discussion
within the team about what constitutes a sprint in agile policy making, I
think it's a difficult but important part to think through. The part about
agile teams seems to be to be a slightly different aspect, one much more
rooted in departmental and civil service culture(s) - whether it's possible
to do agile policy making without a thoroughly bought-in and enthusiastic
team is probably worth a lot of thought as well!
Link to this comment

Reply
Catherine Howe on 31 January 2015

Hi Lisa, Really good to see this theme being explored here. I think one of the
things that is missing in here for me is the need to back up experimentation
with robust data and reflection. I think this helps address the confidence ago
that you might have with decision makers but also makes sure that you are
properly iterating rather than simply responding. Looking forward to talking
to you more about this

Catherine
Link to this comment

Reply

Lisa Ollerhead on 08 February 2015

Hi Catherine, I'm really intrigued by the difference between properly

iterating and responding! Data and reflection are interesting to consider
for me especially in light of Cat's blog and the work Lab have been
trialling with policy sprints which seems to be a way of actually getting
towards actual information. I look forward to discussing in a couple of
weeks!
Link to this comment

Reply

Esko Reinikainen on 02 February 2015

Hi Lisa, I would offer up a slight hack to your first interpreted principle:

Our highest priority is to satisfy the citizens' needs through early and
continuous delivery of viable policy solutions that align with current
ministerial objectives.
It may also be useful to reach for Chris Argyris' (
http://en.wikipedia.org/wiki/Chris_Argyris ) double loop learning for a
theoretical framework that can give comfort to traditional policy makers
around the ideas of wild iteration and crazy pivoting...
Esko
Link to this comment

Reply

Lisa Ollerhead on 08 February 2015

Hi Esko, thanks for commenting! I'll have a look at the double loop
learning model. I really like your amended version of the first principle
and might well nick it - I think the dual customer (users/citizens and
ministers) is one of the more difficult things to translate between
software and policy but this seems to me to be a sensible way to express
it.
Link to this comment

Reply
Tom Wynne-Morgan on 16 May 2016

Hey. I just tried to email Lisa Ollerhead but got a bounce back. If she has
moved on, does anyone know who has taken on the mantle?

Tom
Link to this comment

Reply

Leave a comment

By submitting a comment you understand it may be published on this

public website. Please read our privacy notice to see how the GOV.UK
blogging platform handles your information.

All GOV.UK blogs All GOV.UK blog posts GOV.UK All departments
Accessibility statement Cookies

All content is available under the Open Government Licence v3.0, except where otherwise stated © Crown copyright