On Saturday, I went to UK Govcamp 2015, an all-day event where 200 people interested in innovation, data and digital in the public sector (among other things) get together to talk about - well, whatever they want to talk about on the day, such being the unconference structure. It was my first one and I went along slightly nervous but hoping to learn more about some of the big ideas that are occupying us at the moment on the OPM team, like government as a platform, helping reformers in government network and support each other, and agile methodology for policy making.
Agile policy making and implementation is a popular notion in the civil service 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 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 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 possible: should we try to adapt agile for policy making? If so, can it be done? If so, how?
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 making works and how to tell people to do it - people like DWP Digital Academy and the MoJ digital capability team (and of course Policy Lab - 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 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 manifesto.
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 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 and twelve principles for how to develop software using agile. The main point 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.
13 comments
Comment by wfmtj2395u03jr posted on
'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'.
Comment by Lisa Ollerhead posted on
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.
Comment by Jon Wiltshire posted on
(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!
Comment by Greg Smith posted on
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.
Comment by Lisa Ollerhead posted on
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.
Comment by Nupur Takwale posted on
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.
Comment by Lisa Ollerhead posted on
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!
Comment by Catherine Howe posted on
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
Comment by Lisa Ollerhead posted on
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!
Comment by Esko Reinikainen posted on
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
Comment by Lisa Ollerhead posted on
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.
Comment by Tom Wynne-Morgan posted on
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
Comment by Ade Ariyo posted on
Hi Lisa, Interesting read. 6 years down the line, more departments are adopting "Agile" but not the complete Agile values and principles which makes a mockery of the whole method. Many select to do certain aspects of the event and mention agile in various conversations but never really commit or understand the values. In other to be effective, the Agile mindset needs to be adopted across-board as 'partial agility' can lead to impediments. Most especially in areas where there are needs to manage dependencies. Failure to do this will frustrate departments that decide to embrace Agile.