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.

Title slide: 'Agile service delivery in the UK's public sector'

Hello. I’m Roo Reynolds.

"Hello"

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.

Company logo - "Digi2al: digital services people"

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.

A photograph of the GDS office in Aviation House

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.

A photo of Roo standing outside Number 10 Downing Street

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.

"A brief history of the Government Digital Service (GDS)"

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.

Martha Lane Fox, Francis Maude and a screenshot of Martha's letter to Francis

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 formed in November 2011"

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.

"Leading the digital transformation of government, Making services so good people prefer to use them"

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)

A screenshot of GOV.UK

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?

A photo of GOV.UK being used on a mobile phone

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…

"25 of the most important government services"

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

Another photo of GOV.UK being used on a (different) mobile phone

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

"a multi-disciplinary team - working with colleagues across government"

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.

"agile"

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

"7 steps to construct a building - I imagine"

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

1. gather the requirements. 2. agree a plan. 3. dig up some ground. 4. pour some concrete. 5. build the ground floor. 6. build some more floors. 7. put the roof on

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.

"Disclaimer: I am not a civil engineer!"

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

"7 steps to build a digital service - you'd think"

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?

"1. gather requirements. 2. agree plan. 3. pick supplier. 4.plan the project. 5. start. 6. finish. 7. handover and evaluation"

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.

"7 steps to build a digital service - based on user needs"

Is there a different way?

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

"1. meet the users. 2. understand their needs. 3. build a prototype. 4. get feedback. 5. iterate with constant feedback. 6. make it live. 7. continue to improve"

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.

A diagram of the waterfall approach: "policy formation capture requirements, procurement, development, then launch. What about user needs?"

The old ways of working:

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

Fine. But…

"What if what you make doesn't meet the needs of your users?"

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

"What if you missed some requirements?"

Are you confident that your requirements gathering process was perfect?

"What if things change during the process?"

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

Diagram of the agile approach: "user needs, discovery, alpha, beta, live"

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.

A photo of a big construction site. Lots of concrete and steel.

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.

A photo of an aircraft carrier.

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.

"agile" - photo of a pile of screwed up and discarded paper

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…

Tweet from @psd: "agile: make it up as you go along. Waterfall: make it up before you start, live with the consequences"

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.

Government service design manual

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.

Screenshot of a page from the service manual

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)

Digital by default service standard

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.

"Service performance" - Screenshot of a sample performance dashboard

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.

GDS on github ('alphagov')

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!

"some tips"

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.

"Start with user needs" - photo of Liam Maxwell holding a mobile phone that says "what is the user need?"

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.

A photo of pigs and chickens

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

"When making bacon and eggs for breakfast, the chicken is involved but the pig is committed"

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.

"show the thing"

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.

"five is enough"

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…

A graph showing that as you do usability testing with more users you find more defects. 1 user gives 31%, 5 users give around 75%, 15 users give around 100%

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.

Steve Krug quote: "Testing with one user is 100% better than testing with none"

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"

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.

A photo of a team standing around a wall covered in post-it notes

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.

Photo of a wall covered with graphs, an introduction to the team and other team related information

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.

Photo of a wall divided into rows and columns, covered with small white cards representing pieces of work

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.

Photo of a big printout of a piece of work in progress, covered with scribbles and annotations.

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.

Photo of a wall covered with screenshots that have been annotated with post-it notes.

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.

Kate Towsey quote: "A well tended wall keeps research insights and user needs constant in the collective mind of the project team"

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

"Milk matters"

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.

A photo of a fridge full of small bottles of milk

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

James Daling quote: "left unchecked in a semi isolated environment, cultures can get very 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.

A photo of bottles of milk covered in passive aggressive notes: "BUY YOUR OWN MILK"

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.

"Free to anyone. Contributions welcome"

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.

A photo of a basket of tampons with a label: "this is for everyone"

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

A photo of a nicely labelled basket of tampons in a bathroom

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

'Tampon club' logo

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?

"Thank you"

2 replies on “Agile in the public sector”

  1. Great presentation and loved the philosophy behind the ‘Milk matters’. Living spaces are a great space to find out about peoples habits and behaviours – or their needs.

Comments are closed.