Tag: agile

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.

Intranet iterations

We’ve been doing some more work on our intranet. Here’s a rundown of our latest release and some final thoughts on what I’ve learnt working on this product.

Why take a digital approach to an intranet?

I’ve said in previous posts that intranets can be the scorn of digital purists. “Why not just have a wiki and a blog – it’s totally free?” they cry. Well, maybe.

But as this is my last intranet sprint (sprintranet?) I wanted to make the case for taking a digital approach to this ever present departmental tool. I think there are 4 compelling reasons.

  1. Improved experience for users. The obvious one. Civil servants are users too, and saving them time and effort with products that work is better for them, and better for taxpayers.
  2. It’s a means of spreading digital culture and techniques widely across the department. Talking to lots of teams in the department about their intranet content or involving them in user research has enabled me to introduce principles of agile and user-centred design to lots of people who otherwise would never have encountered these techniques. A good thing in the wider scheme of digital transformation.
  3. Getting content design more widely understood. I’m increasingly convinced that content design training should join information security and unconscious bias as mandatory for policy civil servants. Until that happens, working with teams on their intranet content is a decent alternative.
  4. It’s a good training ground. A staff intranet is a reasonably low stakes environment, which makes it ideal for practising agile techniques, user testing and the like. Particularly as uses are on your door step. Four different fast streamers have now participated in running guerrilla testing or pop up labs in the department, and done brilliantly at it.

On to the highlights of our latest release. As ever, if anyone is interested in playing around with the intranet WordPress theme, it’s available on Github. All comments and thoughts welcomed.

Homepage

In our last intranet post we talked about the changes to the homepage design. The changes have attracted a lot of great comments. But more importantly our ongoing testing is showing users are completing popular tasks more easily.

Of course not everything is working perfectly, so we are continuing to tweak and improve. For instance we found users were not noticing when new content was being posted in the campaign box. So we introduced a ‘new’ banner to signal this event.

Screen shot of 'new' banner on intranet homepage

Information architecture

Our ongoing user research has repeatedly surfaced pain points for users navigating the site. Users did not always understand the main section headings, or what topics might be listed underneath.

To test further we ran several card sorting sessions to try and come up with better labels and a more intuitive architecture. Despite plenty of hard work, it turned out we couldn’t. Naming and sorting things into categories is just one of those timeless problems. We ended up agreeing that what we had was probably the least worst option.

To attack the problem from another angle we introduced some new functionality. We implemented the brilliantly named Accessible Mega Menu. This now provides a drop down of topics that appears underneath a section heading, to help users see what is available and help them answer their questions more quickly.

Screen shot of drop down menu on intranet homepage

Events

The department puts on a wide range of events.  By making use of theEventbrite API, our intranet administrators are able to create and manage events using all the functionality of Eventbrite. Once published, the event details are pulled automatically into the relevant intranet pages. Along with some design tweaks, we’ve made an already excellent events booking process even better.

Screen shot of events box on intranet events page

Our next sprint will be later in the year. Look out for further updates from a new product manager then.  And a final word of good luck and thanks to the brilliant team. My laptop will continue to wear our mission patch with pride.

This post was originally published on the Digital Health blog.

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.