Introducing sprints to policymaking

Introduction

This post discusses what agile approaches can bring to policymaking. It is based on my recent participant observation in a “policy sprint” organized by the Policy Lab in which I am embedded as an academic researcher. The sprint took the form of a two-day workshop held in Whitehall, followed the next day by a half-day stakeholder workshop, during the early phase of a larger, ongoing project involving Policy Lab, the Department of Work and Pensions (DWP) and the Department of Health (DH).

The focus of the project was better supporting people in relation to their health and employment outcomes. The activities involved a co-located, cross-disciplinary and cross-government group of people including policymakers and specialists skilled in ethnography, data science and design research, in exploring a policy issue and working out collectively what research and design activities were needed to move the project on.

Inspired by and drawing on the “sprints” used in agile software development, this event brought a new way of working to policymaking. A recent blog post by Lisa Ollerhead of the Cabinet Office Open Policy Making team, drawing on her experience of GovCamp, in which she adapted the principles of the agile manifesto discussed what agile approaches might bring to policymaking. She concluded that one significant challenge is establishing what the deliverable or output of a sprint is.

As part of its remit to try out new tools and technique for policymaking, Policy Lab decided to use an agile-inspired approach within one of its demonstrator projects to see how these principles could be adapted to the challenge of developing policies, rather than software. A blog post published right after the event by Cat Drew of Policy Lab, who led the sprint, summarised what happened in the January workshop and how it worked.

The purpose of this post is to analyse what the sprint did for the project. The data on which it draws are notes and photographs from my participant observation, emails and documents, as well as interviews and responses to a survey distributed to participants after the event.

Background – agile, lean, design thinking for policymaking

The concepts and activities used by Policy Lab to shape its policy sprint are not new. Within government, many of the principles and activities associated with agile software development inform the work of the UK Government Digital Service (GDS). For example the GDS approach to designing government services that are “digital by default” is shared here, including a discussion of using sprints. Some of GDS’s terminology and approaches are also found in government departments, especially that have in-house digital teams. The space that Policy Lab is exploring bringing this approach to the early stage of making policy, not building digital services.

Internationally there are other examples of bringing design and digital approaches to policymaking, which share lineages with agile software development. The Helsinki Design Lab, part of Finish innovation agency Sitra which was active between 2008-2011 organized “studios”, typically week-long collective inquiries into an issue such as ageing in Finland, the outputs of which included a roadmap of strategic improvements (see Steinberg 2014). These approaches are closely related too to design-led innovation. For example, innovation consultancy IDEO organizes “deep dives” into issues such as the one on the shopping cart filmed by ABC television in 1999, which involved multi-disciplinary teams collectively inquiring into a problem area, generating ideas and creating rough prototypes of potential solutions.

Related principles such as looking at the bigger picture and systems thinking are also found in other UK policy initiatives like the Total Place programme run by the Leadership Centre for Local Government. The Troubled Families programme takes a “whole person” perspective on families and their interactions with public services.

There are also overlaps with lean start-up, popularized by books by Steve Blank and Bob Dorf (2012) and Eric Ries (2011). Key concepts here include rapid experimental cycles in which entrepreneurs articulate their hypotheses, build software in chunks known as “minimum viable products”, test them with customers and then, depending on the results, “pivot” by switching to a different product or business model if necessary.

Within agile software development, a sprint is usually understood as a time-limited set of activities which result in delivering working software. Used more loosely in the context of policymaking, here this policy sprint was an intense burst of activity that focussed on the early stage of a project – called “discovery” in software development, which will be followed by other short, intense bursts of co-design and prototyping over the months to come.

Principles in the policy sprint

In the preparation, design and facilitation of its policy sprint, Policy Lab recombined principles borrowed from agile, design and lean start-up as follows:

  • Recognition that a project’s context cannot be fully understood or defined. Instead, the focus is on enabling a team to form and to work together to achieve something meaningful in a short time frame. Instead of trying to do a definitive analysis, the emphasis is on generating provisional accounts of an issue, and on an orientation towards repeated cycles of collective learning, idea generation, prototyping and synthesising.
  • Staging a collective enquiry into the issue. The sprint event recognised that there is already considerable data and analysis within the two departments involved and beyond. The design and facilitation of the workshop enabled a range of participants from different backgrounds collectively identifying “what we know” and “what we don’t know” to synthesise current knowledge and identify gaps relevant to the project at hand – albeit without being fully comprehensive – in order to move forward the project’s goals.
  • An orientation towards cycles of practical work. The development of new products or software should be based on trying things out with real customers (lean start-up) or via cycles of iteration based on defining user needs, delivering software and testing it with users (agile). These partial, temporary placeholders for solutions are termed minimal viable products (in lean start-up), which is the minimum set of functionality that is of value to end users. Agile software developers use the terminology of alphas and betas, which suggests evolutionary development. The policy sprint was positioned as the start of a project structured with fast learning cycles.
  • A holistic approach to understanding the experiences of the target population and those around them. Lean start-up aims to identify customers’ needs and test hypotheses by engaging them directly. Agile starts by identifying user needs and builds software solutions for them. However the context of policymaking is systemic: there is no single customer and nor should the focus just be on only service users. Instead a holistic agile approach for policymaking acknowledges citizens and service users, but also family members, other members of the public such as neighbours, front line staff and managers in delivery agencies, volunteers, but also ministers and other actors in the wider political and policy environment. For example in the case of this project, the sprint brought into focus the role of GPs, HR personnel and line managers as well as family members, friends and colleagues shaping the experience of people becoming ill.
  • Less emphasis on producing definitive documentation, and more emphasis on co-articulating just-in-time knowledge. The emblematic artefact associated with design thinking and agile software is the post-it note. Along with whiteboards, flipcharts and other such low-fi organizational technologies, post-it notes emphasise the provisionality of ideas and knowledge because they are easy to write on, stick up, move around, edit, or remove. Further, the collective activity of writing things down on post-its and sharing and clustering them on a wall makes collective knowledge and ideas visible to everyone – at least those who are in the room and able to see. Collections of post it notes stuck on to flipchart paper, which are then photographed and shared offer repeated snapshots of the current status of a project. In contrast to the highly polished, formal reports produced by government, such arrangements of small fragments of ideas and knowledge highlight policy making as a work-in-progress.

References

Blank, S. and Dorf, B. 2012. The Start-Up Owners Manual: ‪The Step-by-step Guide for Building a Great Company, Volume 1.

Steinberg, M. 2014. Strategic Design and the Art of Public Sector Innovation. In Bason, C. (ed). Design for Policy.

Reis, E. 2011. T‪he Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses.

Advertisements

Published by

Lucy Kimbell

Director, Innovation Insights Hub, University of the Arts London. AHRC research fellow, Policy Lab, Cabinet Office. Associate fellow, Said Business School, University of Oxford. Author of Service Innovation Handbook. @lixindex

One thought on “Introducing sprints to policymaking”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s