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

Leave a Reply

Your email address will not be published. Required fields are marked *