Tag: policy

Agile policy teams

There’s a brilliant event taking place today. #oneteamgov is having proper crack at bridging the policy/delivery divide.

Anyone working in digital knows what an agile product team looks like. As a fun thought experiment, I wondered what would a multi-disciplinary agile policy team would look like.

  • You would have to start with the product/policy manager. They conduct the orchestra, understand the user needs, and prioritise the ways of meeting them. In a policy context this also means being to be able to accurately channel ministerial intent; i.e. being the relevant SpAd’s best friend. Ideally this person has some experience of working with digital because so much delivery is rooted now in digital services; and digital provides all the best team tools for effective delivery.
  • Next hire would be a delivery manager. When I moved from policy into product I was particularly struck by the rigorous approach taken to prioritisation, enabled by strong delivery management. I’m also a big fan of separating the roles of owning the vision with owning the delivery. Badging policy work in phases like discovery/alpha/beta will help teams chunk up the work, and could have ancillary benefits help… managing… u-turns? I also don’t see why scrum or kanban couldn’t be used in good effect, if only for task management. OK, it’s hard to rapidly prototype and iterate a law once it is statute, but that shouldn’t exclude the rapid generation, iteration and validation of policy ideas and proposals in discovery and alpha. Some interesting arguments for git-based development of legislation have already been made.
  • The 3rd name on the team sheet is design, and specifically a service designer. As well as being skilled at ideation and interpreting needs from research, designers are excellent at communicating ideas verbally or visually and are the kind of people you want in front of ministers. I also consistently struggle to think of a single area of officialdom that would not be improved by better content design so get them onboard as soon as you need to start putting pen to paper.
  • Research and analysis. In the ideal world this is a data scientist with an excellent grounding in social research and epidemiology. The extraordinary difficulty of finding someone like that means you probably have to pick depending on the policy area. Someone comfortable with the micro and the macro would be the place to start.
  • A stakeholder manager. Policy work is so often about accumulating the views and knowledge of as wide a group of people as possible and synthesising that in order to support decision making. Getting around the various interest groups is a full time job. A good communicator, networker, and seller of ideas will get your policy flying.
  • An economist. Because all roads lead to HMT.

There are many more who need to be involved in policy development but above are a few ideas for an irreducible core.

Policy makers will probably read this thinking “Yawn, we do all that already.” But whisper it, I don’t think you/we do. The people I mention above do join together in the civil service, but not usually as part of a specific autonomous unit. They remain for the most part in silos, feeding into lots of different projects at a time. In other words, a bit like IT firms where development is in one department, testing in another, and infrastructure or support in another. A model which seems so old fashioned now.

Agile was described to me recently as “collaboration, iteration, prioritisation”. I think that autonomous agile policy teams can help achieve those things more easily, and deliver better policy, quicker. I’d love to know if anyone’s tried this or what people think.

Update 16:07 on 29 June: thanks to Sophie, Olivia and Matt who have pointed out to me that they would have a user researcher on the team. I wholeheartedly agree.

This story was originally published at Medium.

10 things policy can learn from product

Richmond House

Six months ago I made a career pivot from policy making to product management. The roles require a similar mix of empathy and politics, so I feel I’ve taken to it reasonably well. Alongside a deep understanding of Internet-enabled technologies, a notable difference is how much and how effectively product management makes use of specific tools and methodologies to solve problems.

So here are ten techniques I would bring into a policy team if I went back. If any of the terms don’t make sense, Ben Stevens from the Home Office has posted a handy glossary.

  1. Work in sprints. Choose a time period of 1 or 2 weeks to help give structure to the team’s work. Get everyone together at the start of the sprint and agree the things you are going to focus on completing in that time, remembering that new tasks will come in too. This is called sprint planning.
  2. Hold ‘stand-ups’ over the course of the sprint, and ‘retrospectives’, and ‘show and tells’ at the end of it. Don’t be spooked by the language. These are just meetings, so not exactly an alien concept to policy makers. There’s no need for me to repeat better guidance elsewhere on this, except to endorse how useful they are as an ensemble.
  3. Get a wall. Every team needs a wall. I managed a major house renovation last year and even had a wall (this is not a joke). At its simplest this is expressing a task on a Post-It note, fixing it to a nice flat surface that people can gather around, and moving the tasks through columns labelled ‘doing next’, ‘doing now’, and ‘done’. Do this, and then feel the energy and sense of achievement coursing through the team as they deposit card after card in the done column at each stand-up.
  4. Create genuinely multidisciplinary teams. I spent some time shadowing my mentor who works on NHS.UK Alpha a few weeks ago. It’s a full-blown agile team, replete with product manager, delivery manger, content writers, designers, and developers. Having such expertise around a table enabled them to do magical things, like designing the key features of a GP look-up service, in record time. My experience of policy is usually hierarchical group of something akin to project managers. Other experts tend to be in a box somewhere, wheeled out for special occasions. It also now seems amazing to me that design thinking in policy is still seen as the cutting edge while it’s de rigeur in digital.
  5. Make it someone’s explicit responsibility to knit the team. The mantra goes, “the unit of delivery is the team”, and commensurate effort is placed in getting that team working brilliantly together. My experience working in policy teams is that if they are working great, then great. But if they are not, the response is usually a shrug and sporadic suggestions for ‘more social events’. Digital methodology encourages constant communication between the team using stand-ups. It celebrates successes through show+tells, and does a thorough job of learning from failures through retrospectives. The result is a team completely aligned around an objective, with everyone feeling they are part of something important, and fantastic pace of delivery. Tasks fall to the team not individuals. This reduces risk of single point of failure.
  6. Separate responsibility for day-to-day delivery with big picture and vision. In digital there are overlapping and complementary roles called product manager and delivery manager. The former focusses on macro issues: vision, roadmap, stakeholder management. The other focusses on micro issues: unblocking the obstacles the team faces day-to-day, and doing the team coaching I describe above. This structure recognises something important about our minds being poor at doing two things at the same time. It’s very effective.
  7. Try out some new collaborative tools. Digital teams more naturally have their fingers on the pulse of internet-enabled tools to facilitate team communication, prioritisation, or collaboration. I know IT systems can create barriers to this; but in an age where everyone has a smart phone it’s not hard to find workarounds. If you had to pick any, for me it is Slack. There’s a bit of a backlash against Slack at the moment (Slacklash?), but frankly I’m still at the crest of the wave of appreciation that sees how much more efficient than email is at enabling team interaction.
  8. Prioritise properly. Product recognises you can’t do everything, so have a plethora of techniques for deciding what comes next. Do a few things well rather than lots of things mediocrely, and be rigorous in your approach to choosing which those things should be.
  9. Clap more. Digital teams religiously clap their teammate’s or others’ presentations. This is not only courteous, but sends the presenter away with those few extra endorphins that make it all seem worth it.
  10. Be agile. Note the small ‘a’. My simplest interpretation of this is understanding that for almost everything, your first answer could well be wrong. Doing something and then testing it is better than trying to get it perfect first time. As long as it is labelled as such, it is fine to say something is a prototype or early version and will be iterated, improved, or even binned.

None of these suggestions are especially complicated. But they can be tough to implement in teams unfamiliar with the language and culture. Digital teams should help with this where they can, as forming good habits should not solely be the preserve of digital. They should be for everyone.

I’d be delighted to give my novice advice to any policy makers, so do get in touch if it would help. Hat tips to Lisa, Matt, and Kylie for product coaching, andBenji for delivery management advice.