Making Agile sprints work for services, systems and policy design
Published 2017
Co-written for the Uscreates Blog
Over the last few years, agile methodology has been increasingly taken up by non-digital, policy or transformation teams in the public sector (although when I say non-digital, I don’t mean they won’t be considering digital as part of a fairly standard approach to service provision). You can see why: it’s great at injecting pace and energy into a project. Agile is focused around action over planning, in a similar vein to the JFDI (just f**king do it) attitude which, as Paul Maltby says, often allows something to be created in less time than it takes to get diaries aligned and meetings booked in. The prototyping element of agile allows you make an idea visible and sharable quickly, so you can get more people engaged, either to lend their support (e.g. through lending time, energy or resources) or to test the idea, spot issues early and avoid mistakes. Agile is a Minister’s or Chief Executive’s dream, busting through inertia, avoiding waste and risk and levering in additional resources.
However, agile doesn’t necessarily translate perfectly from digital to policymaking or service design. At Uscreates, our public and third sector clients increasingly ask us to help them work in an ‘agile way’, but we’ve found that – in its original form, or in some of the incorrect ways it’s been interpreted (e.g. as another way of saying fast, unplanned, or only digital) – agile is not always possible nor the best solution for trickier, systemic issues.
This was the subject of a discussion at the recent #OneTeamGov conference, where policymakers, digital experts and service designers came together to explore how to align their worlds. At Uscreates, we’ve also been thinking about a happy medium: not ‘wagile’ (or a return to waterfall from agile), but something which is the best of both worlds.
Reflecting on our experience of using agile in the design of both policy and public services, we’ve outlined some of the key differences and tendencies, in the full report available below, for using it in technology development as opposed to using it to develop systems and services. From our experience there are 3 key challenges to overcome when using agile that are absolutely crucial to its successful integration within policy, service and systems design in the public sector:
However, agile doesn’t necessarily translate perfectly from digital to policymaking or service design. At Uscreates, our public and third sector clients increasingly ask us to help them work in an ‘agile way’, but we’ve found that – in its original form, or in some of the incorrect ways it’s been interpreted (e.g. as another way of saying fast, unplanned, or only digital) – agile is not always possible nor the best solution for trickier, systemic issues.
This was the subject of a discussion at the recent #OneTeamGov conference, where policymakers, digital experts and service designers came together to explore how to align their worlds. At Uscreates, we’ve also been thinking about a happy medium: not ‘wagile’ (or a return to waterfall from agile), but something which is the best of both worlds.
Reflecting on our experience of using agile in the design of both policy and public services, we’ve outlined some of the key differences and tendencies, in the full report available below, for using it in technology development as opposed to using it to develop systems and services. From our experience there are 3 key challenges to overcome when using agile that are absolutely crucial to its successful integration within policy, service and systems design in the public sector:
1. People need to shift between different mental modes
In an ideal agile world, you’d bring everyone together over an intense, short burst of time. People’s heads are in the project, decisions get made, and the job gets done. In reality, that is not always possible. People often cannot dedicate 100% of their time over a week to just one project, while also needing to shift between different mental modes. Operational staff will be concerned with keeping the show on the road as well as improving services. Policymakers will need to shift between making progress on a discrete element of a problem to considering the wider system. Agile sprints need to be adapted to make space for people to be involved, whilst giving them physical and mental time out to do their other work.
Some practical things could be relationship-building activities with the wider team to create a shared vision (and motivation for going beyond the day-job), clear team commitments so everyone understands from the start the time and activity each member can contribute, and some quick re-immersion activities for those who have to dip in and out.
2. Strategic patience is crucial
There can sometimes be a misinterpretation of agile as meaning fast and all guns blazing. People can also get nervous if they don’t know from the start what the outcomes of the sprint will be. Working at pace does not mean jumping straight to the solution, nor getting rid of reflection time and feedback loops. Indeed, with more complex services, taking time to step back and consider how the wider system needs to change to embed the policy or service is critical to its success. Sometimes prototyping is as much the pursuit of failure (to understand why something won’t work and avoid it) as a success (which are really two sides of the same coin).
Some practical things here are to be really clear about what agile does and doesn’t mean in your organisation, and to show people a clear and rigorous process (with case studies) that gets to an end goal so that people can see where they are.
3. Cultural buy in and commitment to agile
Both of these things need a true commitment to agile from the top. Senior leaders need to allow people the time and space to come together to work on projects, and the permission to make small changes and experiments, knowing that while some will fail (and this should be welcomed, otherwise you haven’t innovated), an iterative approach and reflective learning wrap-around de-risks the overall outcome.
Some practical things here… might be having senior management drop ins or show and tells to show commitment to this way of working. Additionally, sharing learning across team meetings or more widely across the organisation about what didn’t work (no matter how small) and the changes made to improve this.
--
This is an emerging practice so it would be great to hear your thoughts and experiences. If you are new to agile, before jumping in headfirst, it’s really important to reflect about whether it is right for your project and organisation. If you’re developing digital products, a hybrid way might also be better as you will be designing digital products within a wider system.
We've outlined below how and where we think the differences for using an agile approach are when designing systems and services in comparison to building a tech product.
Feel free to download the full report (below or from the Uscreates website).
| uscreates–making–sprints–work–for–policy–full-report.pdf |
Image source: Tacita Dean. I love how she captures nature in a powerful and evocative way. Her annotations on her artworks bring a sense of her into her artworks.