Agile in the public sector

I’ve uploaded some slides I put together recently for a couple of events. I’ve also posted my speaker notes below.

Many thanks to Leisa Reichelt and Emma Gasson for giving me some useful tips and links this week, to Alice for the slide template (and, spoilers, for the finale) and to Padma Gillen for letting me steal his construction metaphor. Huge thank yous to the dozens of people whose work I mention below and the hundreds of people who have taught me and influenced me over the past few years.

Hello. I’m Roo Reynolds.

I’m Chief Operating Officer at Digi2al, which is a small agile software consultancy. We help find interesting and challenging public sector work for some of the most talented agile practitioners in the UK.

But that’s not why I’m here.

I was invited to speak today because I worked in the Government Digital Service for a while. When I joined in 2012 were fewer than 50 people there. When I left last year there were more like 650.

I’ve had some experience of transforming government and helping deliver government services as a product manager, both within GDS and now in the world of freelancers.

I’ve learned a few things over the past few years working in and around government service transformation in the UK, which I’d like to share with you.

First though, let’s start with how GDS came about.

In 2010 Martha Lane Fox wrote to Francis Maude, who was then the minister for the Cabinet Office, to make some recommendations about how the UK government could use the internet to communicate and interact better with citizens.

Note the subtitle. Revolution not evolution. She set the government a bold challenge to totally change how it thought about delivering digital services.

The provocation worked. GDS was created the following year as part of the Cabinet Office.

GDS was created with a clear mission: helping the entire UK government with a new approach to building digital services, and making things so good that people prefer to use them over the alternatives.

Pretty exciting stuff.

We transitioned the UK government’s online presence to a single domain, closing hundreds of messy confusing departmental websites (and saving 10s of millions of pounds at the same time)

Because you shouldn’t have to understand the structure of government to use the government’s website when you want to know things like:

• what’s the minimum wage?
• when is the next public holiday?
• what’s the UK government’s policy on Afghanistan?

In the early days, we took 25 of the most important government services and rebuilt them. Things like:

• registering to vote
• viewing your driving licence
• tax self assessment
• renewing your passport
• giving someone the power of attorney
• booking your driving test…

…big stuff. Important stuff used by lots of people.

We did it by bringing together awesome policy makers and digital thinkers.

But it was more than just hiring good people.

Probably the biggest thing that made GDS stand out in the UK public sector was a commitment to working in an agile way.

To help explain that, forget about software just for a minute. How do you construct a building?

I’ve never done it before, but here’s how I think it works

Doing each subsequent floor you might get faster, but you’re not in a position to change direction very much as you go. You’re paying for experts who use expensive materials that can’t be changed easily once they’re laid, like concrete and steel.

It’s important to get the plans right first, because it’s ridiculously expensive to change your mind half way through.

(I should probably point out that I’m not a civil engineer and you definitely shouldn’t hire me to manage any construction projects.)

How would you construct a digital service? Say, a website where people can register to vote?

I mean, it’s important you get to the right result, and the experts you’ll be paying to create the thing are just as expensive, so you’d imagine it’s important to plan everything up front, surely?

Does this sound familiar? Digital services are still being built like civil engineering projects. But digital services are not like buildings.

Buildings cannot be iterated quickly. It’s expensive to change your mind once you start so naturally you want to lock in some plans.

But digital services can move fast. They can be prototyped in minutes, then tested with users and iterated in hours.

Is there a different way?

Being agile and starting with user needs means working something more like this…

Start with users. Work out what they need. But don’t trust your first attempt at that, be ready to change what you’re doing based on what you learn from users. Don’t lock those requirements and agree the finished product before you start, because a lot can change in during development. Whole new devices can be invented and become popular in the time it usually takes to deliver a government service.

The old ways of working:

• capturing requirements,
• procuring suppliers and building something based on those requirements
• then launching, and hoping it works.

Fine. But…

Will you know what you’re building is any good before it’s too late to do anything about it?

Are you confident that your requirements gathering process was perfect?

And what if the policy changes, or a new technology comes along? How quickly and cheaply can you change to match?

Being agile means starting with a good understanding the needs of real users. Not by making a long list of imagined requirements but by researching, prototyping and iterating; regularly and frequently getting feedback and data from real users every week or two.

It means procuring help from suppliers in smaller stages, not all at once.

It means working closely with policy people throughout the process to challenge assumptions and to be brave enough to transform the government not just build websites.

If I was building a bridge, or a tunnel (and I definitely shouldn’t), I’d want to plan the hell out of it and stick to the plan. PRINCE2® isn’t going to fall out of fashion for construction and civil engineering.

But when you’re building a tunnel, the ground is unlikely to move 2 meters to the left while you’re buying the concrete. Your users are unlikely to suddenly grow wings during the building phase and no longer need the lifts. Yet the equivalent in digital projects happens all the time.

Equally, it would be pretty silly and expensive to try to prototype an aircraft carrier, or hope to learn anything by iterating it every two weeks.

But not software. Software should be agile.

Being agile means learning as you go; being prepared to admit you don’t know everything before you start, and that you’ll need to continually improve as you go…

Or as Paul Downey once put it very pithily, making it up as you go along.

When you know that don’t know very much about what the solution needs to look like, it’s scary, but learning as you go is a lot more likely to lead to a good result than trying to specify the perfect solution at the start.

And there’s help out there. There’s a service manual for people building services in the public sector.

As you might have guessed, it’s quite opinionated about whether you should use agile.

It encourages you not to let yourself be limited by your initial understanding and scoping of a service. Not to allow procurement decisions (picking a supplier and setting up a 10 year contract) to limit the work. To procure in small chunks.

There’s specific advice about governance; not to let it get it the way, to have stakeholders see progress for themselves (rather than asking for long reports)

There’s also a mandatory assessment that services have to pass before they can go live.

There are 18 criteria, but look at the first four: if it’s not agile or if it doesn’t have ongoing user research, it won’t go live.

There’s also treasury spend controls, a process for signing off business cases and releasing £ is based on having an agile process in place.

And once it’s live, every service publishes data to a performance dashboard showing live usage data about all government services including things like user satisfaction, completion rates, cost per user, uptime, response time, and so on.

And if you’re looking for a headstart, GDS makes most of its source code available for reuse. There are 345 different repositories + 100 more that are public but not maintained. Help yourselves!

I’d like to share some tips. Some things I wish I’d known when I started out and that might help you.

Let’s get the obvious one out of the way first.

Here’s Liam Maxwell, who until recently was UK Government’s Chief Technology Officer, and his mobile phone cover, exemplifying what makes GDS so special. Even when it’s difficult. Even when it’s uncomfortable. Even when it creates difficult conversations with stakeholders, leaders, even ministers. Every member of every team genuinely wants to put users first.

Because if you don’t start with user needs, you end up doing some pretty silly, and usually expensive, things. The history of the UK government is, unfortunately, littered with expensive disastrous IT projects that didn’t start with user needs.

Here’s an old product manager joke: when making bacon and eggs for breakfast, what’s the difference between a pig and a chicken?

The chicken is involved, but the pig is committed.
The pig, literally, has skin in the game.

As a product manager the first part of my job was often to work out who was going to be responsible for this service, and who will to need updates or just get in the way.

You want to spend quality time with pigs, the people who are actually committed to working with you, and as little energy as possible keeping the chickens updated and feeling involved.

And if you are a stakeholder, don’t be a chicken. Be a pig! If you can, become part of the delivery team.

Probably the biggest thing I’ve learnt is that the sooner people can see something, even a prototype, even a paper sketch, the sooner you can get feedback, show progress and gain momentum.

If it’s terrible, don’t wait. If it’s unfinished, good. You haven’t sunk unnecessary time into perfecting something you might well need to change or throw away.

Get feedback early, and get feedback often. Show it, learn from it, and refine it.

You’re going to be testing concepts with users, and well meaning people are going to ask about how you’ll know the feedback is statistically significant.

If you’re doing A/B testing or surveying people to understand things on a large scale then you’ll need someone who can work out standard deviations and so on. But for user feedback, even 5 people selected at random is really useful.

That sounds very vague, but there is science behind it…

Jakob Nielsen found, across a large number of projects, the proportion of usability problems discovered while testing with one single user was 31%

Meeting a second user, you’ll find they run into some of the same problems as the first user, so there is some overlap in what you learn, but they’ll also add new things you wouldn’t have spotted.

The more users you meet, the less new things you learn about usability from each one. 15 is loads. 3 rounds of 5 would be a better use of your money.

And, as Steve Krug points out, even one is a lot better than none at all. (You could even argue it’s infinitely better than none?)

If one person gets stuck somewhere, you can predict that A lot of other people will have problems there too. Usually what you need is enough to know where you need to make some useful improvements.

Walls are important. You’ll need some in your building. (Again, not a structural engineer but I’m pretty confident about this one)

In a high tech computerised agile delivery office, it can be surprising just how important the physical space it. Walls get used in all sorts of ways.

Here’s the GOV.UK team reviewing feedback from a day of user research about the effects of a particular policy change (shared parental leave) would have on people, and working out what do to about what they learnt.

Here’s a project team using their wall to share their status with anyone who walks past. Anyone can see what they’re up to and start a conversation. Better than a wiki.

Here’s a big wall being used to share status between different teams who need to coordinate as part of a bigger programme of work.

This was how we organised the roadmap for GOV.UK, each team shares what they’re doing, what they’ll be doing next. You can see what’s been done recently, what’s coming up soon and the current guess about what will happen in a few months time.

Here’s a team communicating with each other asynchronously, not needing constant meetings or emails, just by sharing work in progress on their wall and letting people annotate it. You can get a lot done during a day, without slowing people down.

Because nobody wants to be in meetings all day.

It can be really helpful to print out every page of your site or service and then annotating it with comments, insights from analytics, feedback from users.

There’s a great GDS blog post about walls being vertical campfires with examples of those techniques, describing the difference it makes to a team

Two tips left. I want to talk about milk.

When James Darling started working in the UK’s Ministry of Justice, he noticed lots of small bottles of individually labelled milk in the fridge. People had been writing their names on bottles of milk. Teabags and sugar were stored in people’s lockers to avoid other people using them.

As James wrote, perhaps we shouldn’t be surprised when this kind of thing happens, but it does seem a little odd.

Here’s a similar photo from a bank. Rather passive aggressive labelling.

Back at the Ministry of Justice, James noticed not just labelling like this but that someone was even putting food colouring in their special bottle of milk to discourage other people from using it.

That is properly weird.

So. James was keen to improve things. He went out and bought 2 litres of milk, a big box of tea bags and put up a new sign. “Free to anyone. Contributions welcome.”

Within a few weeks nobody was labelling milk any more.

Alice Bartlett did something similar at GDS.

Since the organisation wasn’t providing tampons in the toilets, she went out and bought some for anyone who needed one.

And then, over time, she iterated it and made it even better.

And by sharing it she inspired other people to do the same in their places of work.

I’m properly proud of both James and Alice for the way they they changed the culture in their offices. Neither of them were in management positions, but they knew that everyone has a role in leadership. They both changed their culture. Not in a big way, not in a way that directly helps deliver things faster or better… but indirectly… what difference does it mean to you if the culture where you work is healthy?

What would it mean in your organisations for people to feel empowered to improve not just the products they’re working on, or the processes they’re using to build those products, but the environment in which they work too?