Agile service delivery In the UK’s public sector
•Descargar como PPTX, PDF•
3 recomendaciones•533 vistas
Agile service delivery In the UK’s public sector by Roo Reynolds
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (15)
Similar a Agile service delivery In the UK’s public sector
Similar a Agile service delivery In the UK’s public sector (20)
Más de Smidigkonferansen
Más de Smidigkonferansen (20)
Último
Último (20)
Agile service delivery In the UK’s public sector
- 1. Roo Reynolds @rooreynolds Agile service delivery In the UK’s public sector
- 2. Hallo
- 6. A brief history of the Government Digital Service (GDS)
- 10. GDS was formed in November 2011
- 11. Leading the digital transformation of government Making services so good people prefer to use them
- 12. www.gov.uk
- 13. www.gov.uk
- 14. 25 of the most important government services
- 16. A multi-disciplinary team - working with colleagues across government flickr.com/photos/paul_clarke/6477056845
- 17. Agile
- 19. 7 steps to construct a building (I imagine) flickr.com/photos/lhanaphotography/6107639393
- 20. 1. Gather the requirements 2. Agree a plan 3. Dig up some ground 4. Pour some concrete flickr.com/photos/lhanaphotography/6107639393
- 21. 1. Gather the requirements 2. Agree a plan 3. Dig up some ground 4. Pour some concrete Disclaimer I am not a civil engineer flickr.com/photos/lhanaphotography/6107639393
- 22. 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 flickr.com/photos/lhanaphotography/6107639393
- 23. 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 I can’t stress this enough Not a civil engineer flickr.com/photos/lhanaphotography/6107639393
- 24. 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 flickr.com/photos/lhanaphotography/6107639393
- 25. 7 steps to build a digital service (you’d think)
- 26. 1. Gather the requirements 2. Agree a plan 3. Pick a supplier and set goals 4. Plan the project 5. Start implementation 6. Finish implementation 7. Handover and evaluation
- 27. 7 steps to build a digital service (based on user needs)
- 28. 1. Meet the users 2. Understand the users’ needs 3. Build a prototype 4. Get feedback from real users 5. Iterate, with constant feedback 6. Make it live 7. Continue to improve
- 30. What if what you make doesn’t meet the needs of your users?
- 31. What if you missed some requirements?
- 32. What if things change during the process?
- 40. Agile
- 46. github.com/alphagov A photo with some text next to it
- 47. Some tips
- 52. “When making bacon and eggs for breakfast, the chicken is involved but the pig is committed” flickr.com/photos/ndomer73/2582778532/
- 54. Show the thing
- 55. Five is enough
- 57. “Testing with one user is one hundred percent better than testing with none” Steve Krug @skrug
- 64. gds.blog.gov.uk/2014/09/03/vertical-campfires-our-user-research-walls “A well-tended wall keeps research insights and user needs constant in the collective ‘mind’ of the project team.” Kate Towsey
- 65. Milk matters
- 67. abscond.org/2014/09/25/culture-stories-milk.html “Left unchecked in a semi-isolated environment, cultures can get very odd” James Darling
- 72. www.tampon.club
- 73. Ha det bra Roo Reynolds @rooreynolds
Notas del editor
- /Hahl-Looh/ /(Gooh) Morn!/ I’m Roo Reynolds.
- I’m Chief Operations 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 for 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 big government services as a product manager, both within GDS and now on the outside as a freelancer.
- I’ve learned a few things over the past few years working in and around government service transformation in the UK. I’d very much like to share them with you.
- First though, let’s start with how GDS came about.
- In 2010 Martha Lane Fox wrote to …
- … Francis Maude, 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 challenge to totally change how it thought about delivering information and services online.
- The provocation worked. GDS was created the following year as part of the Cabinet Office. It brought together the policy skills with digital thinkers (many of whom wouldn’t have previously considered joining the civil service) What made them want to join?
- GDS was created with a clear mission: helping the entire UK government with a new approach to building digital services. Making new digital services 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…
- 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. How did we do it?
- We did it by bringing together long serving civil servants and some of the best developers and digital thinkers from across the country. But it was more than just hiring good people.
- The biggest thing that was different about GDS compared to what came before was working in an agile way. You might be wondering if it works, or whether it can really work, or if it can really work in the public sector, or if whether it’s all nonsense.
- But forget about software for a minute. How do you construct a building?
- I’ve never done it before, but here’s how I think it works
- 1 - gather requirements 2 - make a plan. [Probably pick a supplier too] 3 - pick a spot and start digging 4 - pour some concrete [disclaimer…]
- at this point I should point out that I’m not a civil engineer, so there’s probably more to it than this, but it’s more or less this sort of thing, I’m pretty sure
- again.. I can’t stress this enough. Don’t hire me to manage any construction projects.
- It’s more or less this approach. 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.
- 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?
- If you don’t have good answers to those questions, I’d encourage you to look at the other model. Agile service delivery.
- Being agile means starting with a good understanding the needs of real users. Not by making a long list of requirements and being locked in to it, but by researching, prototyping and iterating; regularly and frequently getting feedback and data from real users every week or two. Prototyping, then deciding how or whether to proceed. Then building an alpha, then deciding how or whether to proceed based on what you learnt. Building up confidence before you go live, which because you’re releasing all the time really just means removing the beta label.
- You might recognise this. It’s apparently the recommended public sector approach to project management in Norway. I expect we’ll hear more about it today. It’s “an adaptation of PRINCE2® ICT projects in the public sector in Norway” I can’t really talk much about it because I don’t speak much Norwegian…
- Google to the rescue! - The concept phase: understanding what the real problem is - The planning phase - Implementation phases: build stuff - The ending / the final phase: termination of contracts, archiving documents, handover of project, lessons learned - Realization phase: realising gains, training staff, improvement in live use. Oh god.
- Quiz, of the two models, waterfall and agile, which one does this look most like? Hopefully during the rest of today people are going to be sharing how this can be used to be really agile. I wish you good luck. I can’t see it. Things to watch out for: are you able to procure work from suppliers in small stages, not all at once. Are you working closely with policy people throughout the process to challenge assumptions? Are you brave enough to transform the government through the work you are doing, not just build websites?
- I’m not against Prince2. It does have a place in the world. If I was building a bridge, or a tunnel, I’d want to plan the hell out of it and stick to the plan. Prince2 ins’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. The equivalent in digital projects happens all the time. Whole new devices come along
- 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
- When you’re building services I’d encourage you to learn as you go; be 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.
- Don’t be too scared though. Help is available. There’s a manual for people building services in the public sector. As you might have guessed, it’s quite opinionated about whether you should use agile. Don’t allow your up front scoping to limit the work. Don’t allow procurement decisions (picking a supplier and setting up a 10 year contract) to limit the work. Procure in small chunks.
- There’s specific advice about governance is not to let it get it the way, to have stakeholders see progress for themselves (rather than asking for long reports)
- And it’s a manual but also there’s a mandatory assessment that services have to pass before they can go live. There are 18 criteria, but look at just the first four criteria. 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 has to publish data to a performance dashboard showing analytics, live usage data about all government services satisfaction, uptime, response time, cost per user…
- GDS makes its source code available for reuse 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. 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. Whoever installed this fence wasn’t thinking of the users of the cycle path. The history of the UK government is, unfortunately, littered with expensive disastrous IT projects that didn’t start with user needs.
- 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 most important 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 that, 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. [Photo album coming up]
- 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
- If you don’t have enough walls you end up needing portable walls in the shape of whiteboards on wheels!
- Yesterday, GDS started putting up notices on walls for new starters (and anyone) letting them know that it’s ok to ask for help, and stay away when you’re sick, and …
- 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 pints of 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.
- It’s not unusual. At least where I live. Norway may be more of a communist utopia than the UK, but you’ve probably seen offices like this before?
- As James wrote, perhaps we shouldn’t be surprised when this kind of thing happens, but it does seem a little odd.
- Here’s one from a bank… 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 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?
- /takk!/ (/Hah Deh Brra/)