Yesterday we asked about how to use agile for policy making. Last week, Policy Lab experimented with doing it.
It kind of makes sense that we should kick-start a piece of work about healthy outcomes with a sprint. But not so much in the physical 100m sense, but in a mentally agile sense.
Policy Lab’s fourth demonstration project is to work with DH and DWP to explore how we can improve the health and employment outcomes of those who have - or are at risk of developing - a health condition at work. The idea is to support them to cope with their condition during work and not fall out of employment and onto benefits, which can have further negative consequences for their health (particularly mental health).
Lab already uses innovative tools and techniques more often used in the design and tech space, and this time we wanted to experiment to see how agile methodology could be adapted to use with policy work.
Up until now, we had been running workshops with departments to understand the problem and reframe the question, and then commissioning out work to design experts. This time, we wanted to try bringing everyone together - policymakers, designers, researchers, stakeholders, user representatives: the lot - to develop the work.
First, we created a dedicated ‘studio’ space in which to work in the Treasury building where Lab is based. This wasn’t like any other Government meeting room. Room numbers were switched so we could nick a better space, pictures of Whitehall scenes were taken down and replaced by photos of what users see when they walk into a GPs surgery or forms that they are asked to fill in by employers. If it looked slightly messy and chaotic - fine; that is what helps people feel like they can challenge or add to what is there.
We then spent two days discovering what information we knew and what we didn’t know, putting ourselves in users’ shoes to think about their needs (not the system’s), identifying gaps in our knowledge so that we could develop some clear research themes and questions, and then developing our research methodology. On the third day, we invited stakeholders and user representatives in to check our assumptions and understanding. It’s not often that stakeholders are invited in at the ‘understanding the problem’ stage, before we have any ideas to test and they seemed to like it: “Thought yesterday was great: it really felt collaborative and productive”.
At the end of the (pretty mentally exhausting) three days, we had:
- built a shared understanding of the policy problem and working contexts between the research and design team and civil servants
- flushed out and resolved some difficult questions early on
- refined policy aims and carefully crafted research questions based on what we know and don’t know.
- our assumptions and language challenged by frontline practitioners
- created a large community of interest around the piece of work
Lisa, my Open Policy making colleague, has also been wondering how agile can be translated into the policy world, and has jotted down a few values and principles that might help. They chime with a lot of what happened last week. In particular:
- We were able to respond to change rather than follow the plan - understanding different contexts meant we were able to adapt our methodology to make sure that qualitative data was seen as robust in a world that is more comfortable with quantitative evidence. Not having the workshop set in stone meant that we could adapt it, and used it to kick off some ethnographically informed research with GPs.
- We had built the project around motivated individuals - the sprint event created a great vibe and team spirit, including from external stakeholders who could help with research and prototyping.
- The testing of solutions is the primary measure of progress, and attention to the evidence base and design principles enhances agility - Lab projects include a prototyping phase where we will test and refine some of the ideas that we will co-design with stakeholders (develop phase) based on the evidence from research insight (discover phase).
- User research over bureaucracy - on the ‘hopes’ cards that people used to tell us what they wanted to get out of the piece of work were many aspirations about understanding users’ perspectives, and designing solutions that did not sit on the shelf.
There are some things that are still hard and we need to work better on (or workaround for now). We will have regular team catch-ups but they may need to be by teleconference rather than face-to-face. Finding meetings rooms that you can commandeer as studio spaces are hard to come by (so we need to use bits of wall-space in the meantime). And building awareness of the value of new tools and techniques will take time - and examples - which is what I hope this project can become.