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.
– 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
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.