Update: Full Periscope replay and transcript added on 18 February 2016.
17:50
Thank you for joining us on our first live blog journey. Don't forget, we're keen to hear all your feedback - feel free to comment below.
17:41
17:39
17:37
17:33
17:30
17:25
17:22
17:16
Aaron Snow from 18F kicks off by declaring that he's come with stickers. He's done his audience research.
17:14
17:11
17:05
17:03
16:49
16:46
Data panel in action:
16:30
Here's Paul Maltby's talking about government data:
16:27
16:24
16:10
The Show and Tell sessions went down a storm. Lots of happy, engaged audience members learning more about transforming government together.
Here's some highlights:
Next we have the second set of talks. See what's coming up on the agenda.
16:02
And here's some feedback from the agile session:
15:52
Don't forget to tune into the Periscope live feed from the 'How to be agile in a non-agile environment' session. An accessible version of it will be available on YouTube soon is available now on YouTube.
Update (18 February 2016): Watch the full Periscope playback (transcript available at the bottom of this page):
15:48
From the GOV.UK Verify Show and Tell:
15:09
We're taking a short break now - back soon with updates from the Show and Tells, before the second half of talks start at 4pm.
Find out what's coming up on the full agenda and continue to follow the action on Twitter. See you shortly.
15:04
15:00
You can take a closer look at this map on the GDS Flickr.
14:58
14:47
Pete Herlihy's presenting outfit is proving popular:
14:45
14:38
14:35
14:28
14:26
14:25
14:19
#Sprint16 is now trending across the UK
14:18
14:08
Interesting to see what keywords are being used:
14:00
Eileen Burbidge is up next:
13:50
#Sprint16 is trending in London:
13:47
Matt Hancock talks about collaboration:
13:35
Stephen Foreshew-Cain, our Executive Director welcomed everyone to Sprint 16 and said this:
Everyone in the civil service has a part to play in transforming the relationship between the citizen and the state
Matt Hancock, Minister for the Cabinet Office, is our first speaker today.
13:03
Registration is almost over - the main event is due to start at 1.15pm.
First up will be our very own Executive Director Stephen Foreshew-Cain, followed by Minister for the Cabinet Office Matt Hancock.
Follow live on Twitter #Sprint16 @gdsteam, and keep checking back here for updates, photos, videos, and quotes.
12:48
Not sure what #Sprint16 is all about? Here's the highlights from Sprint 15:
11:45
Registration begins shortly. In the meantime, anticipation is building.
Join the conversation #Sprint16 @gdsteam.
11:30
#Sprint16 is about to begin.
This is the first time we’ve live-blogged an event. The idea is to share the audience perspective, links to more information, and snippets of the day. We hope to start a conversation that will continue long after #Sprint16 is over.
As with anything new, we’re not sure how this will go. We could end up with a fantastic resource and record of the event, but we might not. We really appreciate your feedback and input: this year’s Sprint is all about transforming government together, and that togetherness starts from the ground up. Live blogs included.
We’ll be updating this blog throughout the day, so bookmark this page and check back now until around 6pm tonight.
Feel free to comment below, or on Twitter @gdsteam #Sprint16.
Transcript
Introduction:
On Thursday 11 February 2016 Government Digital Service Head of Agile Adam Maddison @dogbytes, Ministry of Justice Digital Head of Delivery Helen Mott @mottlehen, and UK Trade and Investment Delivery Manager Alex Nash @acjnash held a live Periscope at Sprint 16 discussing ‘How to be agile in a non-agile world’.
Sprint 16 Periscope ‘How to be agile in a non-agile world’
Adam Maddison:
Okay. Thank you very much for coming. For those of you that saw the last session, you'll know what some of it's about. We need to be quick, not least because this is being broadcast live over Periscope, which is certainly the first time I've ever experienced that. Thank you very much to those of you on the Internet, who chose this session to be the one that was broadcast live. Periscope is awesome, but we're very aware that its accessibility is not quite what we would like. So we will produce a transcript of this session and we will tweet where that transcript is so you can find it.
Hopefully, at the end of the session, if we get through more quickly, we'll have some questions, both from Periscope users and from the audience here. So, if you're on Periscope, please do send your questions in. And if the Periscope session is really popular, we have agreed that we will run this session again, possibly slightly longer, so some more time for some questions. Okay, so that’s the technical stuff.
Very brief introductions. My name is Adam Maddison. I'm Head of Agile at Government Digital Service.
Helen Mott:
I'm Helen Mott. I'm Head of Delivery at Ministry of Justice Digital.
Alex Nash:
Hi. I'm Alex Nash. I'm a Delivery Manager at UK Trade and Investment.
Adam:
And we're all from a cross-government Agile community, which has been looking at some of the very particular problems of trying to be Agile and government.
A quick poll. Who thinks being agile in government is easy? No? Oh, yes. Thank you, Fritz. You work in GDS. Who thinks it's difficult? Yes. It is. We all struggle because we all have the same constraints.
So we thought we'd start with a very brief reminder of what Agile is. Agile is just simply a set of values and principles that some software folks put together to describe what they thought made development of software easier, what was important in successful projects. That’s all it is: values and principles.
One thing that the software community is very good at, and particularly consultancies are very good at is telling you, selling you what you should be doing, selling you a framework and a methodology. One thing they’ve not been quite so good at is saying why you should use Agile and when you should use it. So we just want to cover that very briefly.
Why use it? Because Big-Bang development is very risky. Working in an iterative and incremental way will reduce the risk of delivering things, wasting time, wasting money on stuff that doesn’t actually meet users' needs. It's really as simple and there's a lot of evidence to say, "Yes, it does work in certain situations."
When should you use it? What are those situations? When you're building something new. When you… Undoubtedly there's going to be uncertainty about what users actually want. So that’s a good thing to do. And, particularly if you're working in the constantly-changing environment, like technology, it always amazes me that the iPad is only five years old. Technology is moving very quickly, particularly for people my age. And apparently government policy changes quite a lot.
So, if you're building something new, if you don’t know what you want to build and you're working in a changing environment, Agile is very good. It's not quite so good or it's not the best approach. When you know what your users need and there's something you can buy off the shelf, if there is, buy it. It's as simple as that.
And also, if you are working on something where the cost of change is astronomical and the example I always give is building the Millau Viaduct. You really don’t want to iterate where the foundations of the Millau Viaduct are going to be. Do a big plan upfront. I'm really happy with that. And, as I read somewhere recently, you really don’t want to fail fast if you're building a nuclear reactor. That would be a disaster.
I've got this slide. I didn’t realise that Simon Wardley would be here. He's in the front row. But he is. He may recognise this. It's a very simplified Wardley Map. Complex programmes will require a mix of approaches. So you need to use the right approach for the right thing. Wardley Mapping is a great technique that can help you to decide which approach to use on which component.
This is a very simplified map of High Speed 2. There are all sorts of components down towards the bottom and towards the right where you can use commodity products you can outsource to utility providers. You want to focus on reliability and consistency and reproducibility down there. Use approaches which are good for that.
Six Sigma was very popular in government a few years ago. Keep doing that stuff. But if you're building stuff that’s very close to the customer and customers don’t know exactly what they want or you're building stuff which is brand new, like the BIM, whatever that may be, use an Agile approach because that is going to help you reduce the risk of delivering the wrong thing.
So developing in an iterative way, delivering small chunks of value rapidly is going to reduce the risk of building certain new things. That rapid delivery obviously depends on your context. In GOV.UK, we deploy roughly five to six times a day. Amazon, as far back as 2011, deployed every 11.6 seconds. So they are very frequent. Even deploying, delivering something every two weeks and getting feedback based on that is going to absolutely deliver the right thing for your users.
It's that quick, frequent delivery and reacting to change, which can be difficult in an environment of high control. Yes, we work in an environment of high control and it's some of those constraints that Alex is now going to talk about.
Alex:
Thanks. So, yes, Government, it's an environment that’s basically characterised by pretty strict, top-down controls and processes. And, for the most part, those were put there for pretty good reasons. We should always be really conscious that we're accountable for spending public money and that we're tasked with delivering vital services to some of the most vulnerable people in society. But often, those processes can conflict with an Agile approach that’s built on an ability to quickly respond to our increasing understanding of our users' needs.
So, first of all, important disclaimer. The three of us will not sit up here trying to say that we know everything. We don’t claim that. Delivering iteratively in government is really, really hard. There's always more to learn, whatever your experience, and we're hoping everyone's keen to learn how to do it better, which is why, as Adam referenced at the start, there is a cross-government Agile delivery community. It's made up of people from all across Government, from big famous departments: DWP, Home Office, to those sort of just kicking off their digital journey. So UKTI, where I come from today and places like the Valuation Office Agency, which I met with last week and they’ve got some fascinating problems to solve.
So we asked the community to share their pain points with us so that we could share them with you. And we got back some pretty obvious ones, things that I think are going to be familiar to anyone who's ever tried to deliver a project, Agile or otherwise, in government or probably in any big organisation. There are also some less obvious ones, things that may not strike you immediately as impediments, until you start delivering quickly and you're wanting to make continuous changes and improvements to your service.
So yes, well, that's a load of problems. You're probably looking for some practical solutions and tips on how to solve them. As I said, we don’t have all the answers. We don’t have a magic wand or silver bullet and we've got like 10 minutes. So what we've got is some examples of work that's been done to try and make things more agile and some real-life case studies of where that’s really helped to improve services and improve what we're delivering to our users.
First up, I'm going to be quick: Digital Marketplace because this has already been pulled up in the keynotes by the Minister as an amazing thing. There was a whole lot of talk about it just before this. It's a great way to buy the things you need to fit the Agile development cycle on the Digital by Default Service Standard. And it's improving with the introduction of the outcomes and specialist framework, so allowing you not just to buy hosting commodity products easier, but hopefully to really get the skills in that you need to deliver your services.
Adam:
This is Hilary Spencer, a very large photo of the Director of Civil Service Learning. I talk about her because I'd spent a couple of months sitting with their team and she had a glorious understanding of how Agile should work. Her service manager, who is in the room, asked for a bunch of money, which was not too dissimilar to the cost, the upfront cost of the system that was going to be replaced. And this money was just for the alpha. So you can imagine her reaction when she was presented with this thought that actually we might just throw this thing away after we spent your money. Thank you, Hilary. How's that?
But while she did quickly come to an understanding was that the whole life cost of the existing system, because of the way it was delivered and deployed and was built without addressing user needs or understanding some of the technological constraints, the whole life cost was astronomical. So it quickly became apparent to her that using Agile business cases, and there's some really good guidance from HM Treasury on that, completely made sense because it allows you to invest time upfront to make sure you really can meet your user needs.
Helen:
The Universal Credit digital team, you may have heard a little bit about this, they are building their digital service a bit at a time, which obviously allows them to test that service with real users, understand where the pain points are and use that information to iterate and improve and form the subsequent development of that service.
Now, I'm familiar what most digital teams in government should be doing. The crucial difference is that they're able to use that same approach to inform policy development. So although the policy intent of getting off benefits and into meaningful work won't change. They're able to use the evidence of how these users interact with the policy and the product in real life to inform small changes to areas, like commitments and sanctions, to ensure that the service works better for those it's meant to benefit.
And, on top of the other areas that we've already discussed, the area, the difficulty that continuously comes up in the community is working with people outside of the team. And this is not a new problem. It's not something that's just with Agile, but it is highlighted by using an Agile approach because we require much more active and ongoing engagement from our stakeholders when we're delivering, using an agile approach. And that requires… So that means that we don’t just require a process change for Agile, we require a culture change. And we all know culture change is big and scary.
But it's not impossible so we've got some tips from you, from the community. First up, we need to be respectful of current ways of working. Process is implemented for a reason, as Alex highlighted, usually to prevent something very bad from going wrong, not just to get in our way and slow us down. But that doesn’t mean we can't challenge the status quo. It just means that we need to be mindful that the person responsible for making sure that that bad thing doesn’t happen is not going to be persuaded that we get to ignore the process just because we say we're Agile.
We need to understand what that process is there for, what purpose it serves and then we need to work with the people who are responsible for that process to identify whether there's an opportunity to do it in a better way now. And continuously remember that those outside of the team are not the opposition. We're all here for the same goal: the best use of public money to improve the lives of citizens and we will only be successful in doing that if we work together effectively.
It is, of course, okay to use the language of Agile within the team where we can ensure that we all have a shared understanding, but we do need to remember that words like 'sprint', 'stand-up', 'demo', etc., are shorthand and we can't assume a shared understanding with people outside of the team. And if a word isn’t understood then the detail of what we're saying and why that’s valuable is completely lost. We need to describe the what and why behind the words that we use. So don’t just say, "We have a daily stand-up." We need to explain that we meet every morning to ensure that we're all aligned on priorities for the day.
We found that a kick-off meeting is an excellent way to assure that and to get alignment around this. Not only is it an opportunity for stakeholders to understand Agile ways of working and the terminology that we use, but crucially, it's an opportunity for the team and the stakeholders to both understand how that way of working will fit with their current way of working.
Most importantly, we need to show you that our approach works. Trust has to be earned. We can't expect people to trust us just because it's one of the Agile principles. We need to show our work. We need to demo as often as we can, do presentations, invite the world to our show and tells, get things up on the wall, but most importantly, show that it's making a difference. Show stats. Show how much time has been saved by your product. Show how much happier your users are. Show how much costs have been reduced. We need to continuously show that the effort and, therefore, money that is being invested is worth it and that we'll be trusted to continue doing what we're doing.
And it turns out people are busy. All of our senior seat stakeholders have full time other jobs, sometimes multiple other jobs. So we need to take our work to them. If they understand what's going on in the products, then they can be our ambassadors in other circles. And over time, as they see the value that our demos bring for them, they might start coming to you.
A number of our teams have very senior stakeholders attending demos regularly, but that didn’t happen overnight. It took dedication from the teams to demonstrate that that was going to be a good use of those senior stakeholders' time. You may have spotted on the previous slide Francis Maude attending Alex's demo at UKTI.
Adam:
And our experience shows that this does work. If we respect and understand each other and work collaboratively then you really can make a difference. We have got a short video, but because the morning session overran and the afternoon session must start on time, we're a bit constrained by time. But it's an old video. It's Alan Eccles, the Office of the Public Guardian, talking about the transformational change that happened to OPG. So it's a really good video we will tweet out for those of you watching on Periscope, we will tweet out the link to that video shortly.
A reminder people on Periscope, please do ask questions. So I will jump over that video really quickly. It's a really good video, trust me. We know it's hard. We all suffered the same pain. And we know you can need plenty of support to maintain the energy and enthusiasm that you will need to do this right and to make this change happen. And that is why we have this cross-government Agile community.
It's a bunch of people who are trying to work across all sorts of areas, delivering really good things, really good services and products for our users, for the benefit of our citizens. So if you are interested in joining that community, please do go to that URL. That’s the easy way to do it. You can get to it from every single government department and agency we have checked. Those are the kinds of constraints that we work under.
So that’s our presentation. Any questions? We've got about three minutes before you all have to rush back to the main auditorium. Any questions? Yes. Who's got the mic? Somebody's coming to you with the mic.
Audience member:
Hi there. How do you use Agile when you're in different locations?
Adam:
Before I joined GDS, I worked in an organisation where I was based in London. My development team was based in Edinburgh, coaching Wales in Jamaica. Wales and Jamaica only have one person each. And they actually worked really well. We just communicated constantly. We had Skype open all the time. We had daily stand-ups. They were sitting down because nobody actually worried about doing that, but just keeping that constant, open communication works well.
It is difficult. You need the same things. You need your product manager or your product owner, whatever you want to call them, to be available to the whole team at all times. It's particularly difficult having people in India and people in Jamaica where the time that actually overlapped was miniscule. But as long as we kept talking to each other and kept collaborating, kept communicating, it actually worked really well. We delivered really good stuff.
We've got a question from Periscope, I'll have to squint, from Nick Muddle who were leading lights in GOV Agile that others should learn from? Who were the leading lights? Does anyone ___. (Laughter) There are some amazing people. There are some amazing service managers, the likes of Keith Collingwood, who's doing amazing things around government.
But there is a community so there's a community of people who are all trying to do this thing. So I think that’s part of it. There's no one specific person. Maybe there should be. Maybe there should be a thought leader.
Alex:
I'll burn just a couple of egos. When I first started in MHA Digital, I went to the service manager training so names I wouldn’t mention at GVS at the time, now out in other departments, Jamie Arnold and Mark Stanley are both amazing.
Adam:
Yes. Any other questions? Another question from Periscope from [small talks]. How do you get buy-in from staffing that might not be sold on Agile culture change? That’s a very good question. Who's got a really good answer?
Helen:
So one of the teams at Ministry of Justice Digital have been building an internal-facing application for the delivery of fee omission so help with these when you can't afford the full court fee. They have inherently taken an iterative approach to delivering that staff-facing tool. And have been working with staff across the country, showing their work as they go, getting them engaged, getting feedback on the prototypes, on the live version and showing that they can make changes as a result of how they're actually interacting with that tool. One minute left.
Adam:
I think that’s the main thing: working in an agile way, actually, it really motivates people because they see success. They see change happening and they're empowered to make decisions if you have the right culture. So it really does help. It helps spread the culture.
Any other questions? Yes.
Audience member:
Oh, hi. Any sort of tricky process that sometimes hit a bit of a loggerhead when it comes to things like final processes. So [inaudible] processes where [inaudible]. Could you get [inaudible] terms [inaudible]?
Adam:
Yes, so the question from the audience, for the benefit of Periscope, iterative sign-off processes are difficult. How do you hit that? How do you work with those? Address your processes. That’s what we're talking about. Exactly what processes are actually offering value, adding value to delivery and what's actually just slowing you down? If it's slowing down, stop doing it. Understand why it's there.
Helen:
Understand why it's there. And, if you can do it in another way, try and find a simpler way that isn’t going to slow you down to the same degree.
Adam:
That's it. I'm afraid that’s all the time we've got. Thank you very much for your questions. Enjoy the rest of the afternoon.
4 comments
Comment by Amanda posted on
I was at #Sprint16 but found the live blog useful too. A good bookmark to pull everything together and somewhere I can go back to for reminders of important points. Will the slides be published? Will be useful to show colleagues. Thanks for a great event.
Comment by Louise Duffy posted on
Hi Amanda, thanks for your feedback and we're glad that you found the live blog useful. We'll be doing a roundup of Sprint 16 early next week so that'll have more content from the event.
Comment by Roger posted on
As one of the #GDSteam not able to be at #Sprint16 today, I really appreciated the blogging from the event. You might also be pleased to hear that there was a great deal of interest from far afield. The offices I visited today were following the blog and discussing the content. Something to build on for #Sprint17. Well done all.
Comment by Carrie Barclay posted on
Thanks so much for the feedback Roger - really appreciated and glad that we sparked some interest. Hoping to continue the discussion about transforming government together for many days to come. Carrie