Andrew Hawkins

I'm talking about the story, or journey, of improvement that's going on inside LV now. With the numbers, you'll find we're saying it's still a journey. We're not there yet. So I hasten to add, all the way through, we're still on the way.

So, to get us started, a bit about us. Yes, there's only me, but I've been in IT quite a while. I should, in theory, be one of the dinosaurs, but I've got this horrible affliction: I like tech and toys. I like getting my hands in the nitty-gritty, the new methodologies, the things that change and influence how we create value for our business.

Somehow, I don't think I'm going to stop yet. They still let me play with the toys.

But in that partnership, I'm the dev guy. Robin, sadly, can't be with us to present today. He was due to be on stage, but he's recently had surgery, so he's told me he's watching the live stream. So Robin, if you are, get well soon. If I get it wrong, I've turned my phone off.

But there's a story behind how we came together and how we ended up working. An ops guy and a dev guy working together back in 2011 is an unusual starter.

Before I dive in, a bit about us. We are LV=. You may have known us as Liverpool Victoria. We rebranded in 2007. We've been around for a while. Originally a burial society, we now do insurance, investment, retirement solutions.

But there's a vision to be Britain's best-loved insurer. You may say that's a strange metric. How do you measure best-loved? Well, it seemed our exec team did know what they were doing when they were doing that. Because you look at the consumer surveys, you look at the information being fed back, the experiences, the key pieces coming back from our customers. And it's safe to say, they like you.

If you go back a long way, a lot of you might never have heard of LV=. I'll lay odds every time you see the advert on the telly, you have that tune stuck in your head for hours.

But we've grown. Third-largest car insurer, over 5.7 million customers and still growing. Six thousand employees. I hasten to add, about 10% of that is IT now. But it's a great place to work. That best-loved vision resonates inside the company as well as out to our customers.

So why "horses for courses"? You get a lot of us talking about unicorns. You see enterprises as horses. Okay, but actually, guys: cart horses, hunters, cross-field eventing, Aintree racetracks. There are different speeds and ways we need to work. Our companies demand different paces of us. So there's an akin to that: which horse do you pitch for which course?

But there is an equality of that in people. People fit different situations. We know that ourselves. You find yourself comfortable in different scenarios and practices and areas. But people have this fantastic ability. They can adapt. They can learn. They can change. They can consciously choose to do something different.

I know that happened. I did it myself. If I go back more years than I care to remember, if any of you have come across Belbin or Myers-Briggs, I was so far down in that left-hand corner, you went through a dozen doors and into the cellar before you found me at the keyboard.

But I had the thing you need to support that. I had great leadership. I had good management. I had support. I had time invested to allow me to grow and adapt. Slowly, they unchained me from the keyboard and took me out of the cellar, introduced me to light. I'm not sure I quite like it, if you saw my setup at home, but hey.

But the key thing behind this, that adaptation, that piece, a theme that came out yesterday that resonated well with me, is this speed of adaptation, this acceleration of pace is constantly happening. It's picking up. None of us can keep up with every technical change that's coming along. We can't learn every new language, every new skill.

But we can retain the ability to adapt and to learn. We can have people around us that become the SMEs, the people coming through new and fresh with those things first on their horizon. They become part of your systems, your SMEs, your technicalities, and things you can draw upon.

But I will say there's fitness and discipline key behind this as well. I mean fitness in terms of your stamina, your tenacity to keep going when you hit the aversion to such things as these enhancements and changes.

The piece we're running through starts as a piece of an automation story. But part of that is about, actually, how do you get that first hurdle in the door? How do you overcome that aversion and that capability to get it through there?

But also there's a discipline. The discipline that says, remember why you're there. Are we there to do process, governance all day and practice? No. There are things that underpin what we do. We're there to create value for our customers, our members, the businesses we work for.

You see people talk about value chain mapping, pieces along those lines. If we have the discipline to remember that through each piece of technology we work with, ultimately, we're adding value.

So we run through. We're looking at it from whether you're a cart horse dragging legacy behind you, whether you're this racehorse, whether you're this shire, there is a speed of change in adaptation that causes these transformations to occur with the belief behind them.

So, drivers for change. Where did some of this come from?

Apologies at the back if you can't quite pick that one up, but our key senior execs put a view out in 2012 that said, "We're doing great. We've got amazing growth. We've come from 2007, in rebranding, to grow as a mutual. In 2012, there's great opportunities. There's great performance coming through, but our competitors know that as well. They're not daft. They know there's opportunities there. So what have we got to do? We've actually got to be more agile. We've got to be faster to market. We've got to be innovative. But the other side of the coin is we have to be stable. Oh, and we have to reduce cost at the same time."

Always a nice one to see when the budgets come through. But it's a significant challenge.

So where did that take us? That took us over to our vision piece that said, "Actually, we want to get twice the volume of change through." Not much there. Zero change-related defects. So when you put it in, it's not allowed to go wrong. Stack your throughput up, bring your quality up, and by the way, bring the cost down at the same time.

I'm sure you've all seen that PM triangle: time, cost, quality, and what happens when you try and crunch just one side of that. Let's say it was an interesting challenge.

And behind that, I'd be very surprised if there wasn't somebody in the room who'd come across these style of challenges. We're an old company. We've grown by acquisition as well as internal growth. So we've got complex legacy systems. We've got mainframes, we've got minis, we've got middleware layers, desktop applications, all with a slow pace of change and a high cost of development to them.

We've got duplication. Duplication through simple acquisition. It's quite astounding. One of the things I dug around with in the early days was, how many ways can you do an address lookup system? We stopped counting about 20. Good news is today we've got one. Thank heavens.

But these things are hard to consolidate because people understand different implementations. Teams do things in disparate manners.

But the right-hand side of that: skepticism. It's too hard. We're going to have to go backwards to go forwards. How is this going to deal with zero defects when we've got to pick apart everything we've done? And we already know it's hard. How do we do it? Why are we doing this? Because it just works. What do we achieve with it?

One of the biggest challenges of it all is the engagement side. One thing I regularly tell people inside LV= is when they talk about DevOps, they start talking about tools, they talk about structures, automation. I keep on banging back: DevOps is people.

Ultimately, skills change, technologies change, methodologies change, but your people are the things you invest in to bring this stuff together.

So we needed to get that engagement right. We needed the buy-in at all levels. We needed to try and help overcome some of the protectionism that naturally grows in large organizations and improve how we communicate.

And seeing all that up front, you're thinking, "Actually, just haul them off to the glue factory." Just another slow-speed horse, cart horse. We'll do it a different way.

So what did we do? We started off pretty traditional. No, we didn't haul us off to the glue factory. I'm still here.

We had a change and a run team. So at that time, I was working on possibly the biggest project that LV= had ever done in a lot of years, refreshing our whole claims system on our general insurance business. But not only doing that. We introduced Agile practices at the same time. We introduced new tools, new technology. We even managed to build our first continuous integration chains and some stages of continuous deployment. They never did see a production, but it's one of those challenges. People were still learning.

And as Gene said, risk-averse. Hold on a moment. Biggest thing we've ever done, and we've just done all this new stuff. How hard can it be?

But at the same time, Robin was coming in. He joined up with LV= to create a service called Dev Services. This is quite an interesting concept. It split away DBAs, middleware, Unix, Microsoft guys from the Run Ops area, lumped them over into the change team, brought them closer to the development guys.

We didn't call it DevOps. We didn't know what it was labeled at that point. This was early doors. But the behaviors changed because we brought them closer. It gave them that opportunity to behave differently, and it made life easier for some of the projects.

At that point, I jumped in and started working with Robin. I took on the DBA middleware team. However, I managed to persuade him, the couple of guys I'd recruited into the claims project doing all the CI and CD work, they fit Dev Services. Come on, let's take a risk. Let's bring them in. Automation's this new piece. It's great. It can make this difference.

So we came up with this concept. We labeled it a build team. It was really more of a glue area that was trying to get the developers, the operations, the release guys working closer together to get this stuff going quicker.

Now, it was a hard sell. People didn't get it. There were worries about control. There were worries about chaos caused. How we release it, how we govern it, how we'd manage it, how people would take to it, what about their jobs? These are fears we had to work through and communicate and help people understand.

I remember a great point as Robin was picking up some of these pieces. I gave him a copy of Paul Duvall's book, Continuous Integration. Nice short entry piece. Gave it to him just to read on the train, have something to browse. Two days later, he's back in. He said, "I get it. Wow, what can we do?"

So personally, I thought I'd just broken that first barrier. We'd got a piece over there that said, hold on a moment, a dev guy and an ops guy both get it and both want to help make this change. What do we do?

So running in, we drew up our pitch. We thought it through. We grandiosely labeled it enterprise automation. We had this huge vision of automating absolutely everything.

Oh, boy, little did we know.

But if you haven't got the vision and a target, what are you striving for? How are you going to get through there?

We got lucky. Robin's great as a people person. I've come out the introvert bucket. I'm still doing okay. I'm hitting the side of Myers-Briggs in the top right now, so we're slowly getting there. But he's a bridger. He gets to people, the politics side. I get to the tech and the teams. It works as good teamwork. We are doing our own personal DevOps between us.

But he pitched to our CIO, and lo and behold, he stuck his hand in his pocket for us. He got it. He funded our creation of tools, technology, and recruitment to build our core automation platform.

So if I delve quickly into how we created it, yet again, still at this point, we hadn't read The Phoenix Project. I had a copy of The Goal sitting in the back of my shelf somewhere in the house, but I hadn't got it first time through.

But we'd done something that made sense. We actually formed small-scale Agile sprints to take our own medicine in creating our own tools. So we grabbed in dev, DBA, security, Unix, build guys, PMs, release management, all into the story that we're creating. Purely just for automation tools to start with.

But the understanding that grew out of that creation piece was fantastic. We went through small iterative steps. We knew we were going to be under the microscope. But actually, guys, we got security on board. Well, let them audit it. Prove it's solid and stable. Show them how we want to do quality gates. Show how we want to make the difference.

Now, I'm aware I'm talking at everybody who's seen CI and CD and they know automation, it's a key piece. Look through CAMS, it's only one of the letters. But it was introducing behavioral changes in how people operated and talked to each other. It was a vehicle that enabled us to progress the method and approach.

So we took our own medicines. We went through the small steps. What happened is we created solid and stable systems that people were able to consume without fear of them falling on their face. Very nice in the IT world. So we'd almost gone down our own zero-defect piece to start with. Somebody did manage to break it once, but we took him out for pizza and we sorted it out afterwards.

But what did we do with it? And that's one of the great pieces from our side. Let's take a challenge. Let's not do it the easy way. There are teams over there doing the Java stuff, we can pump through it easy. Okay, they'll get it. We will work with them. We'll work with them as we introduce it, but let's find a challenge.

Oh, we've got a team that's got legacy, it's got new stuff, it's got disparate systems spread across sites. It's got technical debt, it's got backlogs of work. Huge challenges about how they're generating the value.

We got the usual piece. We started off wanting to do a presentation to about half a dozen people and how does it work. We ended up with about 70 people in the room on the site. We had the management, we had the PMs, we had the BAs coming in there, watching what's going on and what we're talking about.

They were giving us a clear message that actually we're interested, we're listening. So whilst there was a certain underpinning skepticism, there was something that gave us a vehicle to sell it.

So yeah, it's still CI, some aspects of continuous delivery, but there was a key moment from my mind there, and it wasn't about the tooling. We had PMs, DBAs, dev guys, build guys communicating by email, strolling across the office, quick notes, phone calls. Information was being lost. Value was being taken away. It was a constraint in how we behaved.

They got let loose with our new task management piece. Inside a couple of weeks, email had disappeared. They phoned each other to have a chat, but everything was tracked under the toolsets. Their comms and collaboration was done by a series of exchanges. They had somewhere to document what these things meant, where they could all share it, and it was clearly visible and available.

So whilst the culture and the behavior pieces are key, something has to help to trigger it, and we found tools did a nice job for us on that front.

So I shoot sideways. We were recruiting at the time. I will drill... drill. I will dwell briefly on our recruitment piece. As I said at the start, there's so much technical capability and knowledge and skills that we have to retain and be capable of dealing with.

But we recruited for problem solvers. We recruited for the mindset. We wanted people who could rise to challenges and problems and issues irrespective of the technology. They'd delve in, they'd learn.

How many times do you talk to some of your tech guys and say, "Okay, just give us the book. Give us a few days. We'll go dig into it. We'll learn enough to be able to answer some of your questions."

We wanted somebody who liked a challenge, and boy, did they have a challenge. If anybody's ever tried to automate Oracle version 6 Forms and Reports and do code quality checks on PL/SQL, I'm happy to have a chat. It's not pretty, but it's possible. You can achieve this.

But they got embedded there. They were part of the team. They lived and breathed the challenges that the team was working with. The DBAs were closer. They had a communication mechanism. These things happened.

Now, if I just jump sideways to another one of the projects. We've got the Java guys, the ones who already get a large portion of this. They adopted this new toolsetting. Now, they did some fantastic pieces with this. They took their own behaviors and techniques leaps and bounds ahead. They were helping push the stuff that we were trying to create. So, great. Our push-pull mechanism was already changing around.

And there was a piece behind this that I got a call one day and I said, "Well, what have you done?"

"What do you mean, what have I done?"

"Well, we just had to cut two weeks off a test cycle."

"Okay, what does that mean?"

"Well, those guys have used that tool to such an extent, they've delivered into the formalized testing guys. They had six weeks allocated for this. They've run out of bugs."

I had to stop and check. Run out of bugs. How many people in the room have ever come to a situation where somebody says they've run out of bugs? It's heaven. It's nirvana. It doesn't happen that often, but boy, was that a great day.

So this is the kind of piece I'm going into.

I'm referencing back to notes there. Quite a short-notice stand-in with the piece. Try and keep the thing flowing.

But this kind of thing came along. It was happening. We discovered the label. We were partway through this journey, and we heard about this thing called DevOps. Copies of The Phoenix Project popped up. People started consuming and understanding. The Goal turned around, Toyota Kata did. Till that point, Continuous Delivery was our bible. Every build manager, every dev guy was distributing their own copy around, many-thumbed and broken. But we had something to base on what we were trying to do. Had ideas and approaches.

I remember a great evening. I was sitting down with Robin and a couple of the build guys, chewing over, well, what does this mean? How does this change? Could we do it? Because we've got silos everywhere. We've got split functionality. These things are still challenging us.

But okay, what one of these could we do? Why can't we? Well, what stops us? Yeah, I know that bit stops us, but what if it didn't?

Okay, open spaces. That brings people together. We can't force teams and resource behaviors to change, but we can bring people together.

A few weeks down the line, we trialed our first open space. DevOpsDays, however you want to phrase it. We brought people from multiple communities and areas together and said, "Actually, guys, what are your problems? Here's a nice big sheet of paper on the middle. Here's a bunch of Post-its. What do you want to talk about?"

We facilitated, we helped. We sat them down in front of the DevOps history videos. We stuck the videos, Jez Humble on there saying, "Actually, don't recruit your DevOps. Build them, train them." We got people to understand a different ethos in thinking.

Next thing we know, we've got queues at the door. "Next one you run, can I have an invite? We'd really like to come along to that." It made a difference to how our guys are talking. They realized the fact there wasn't an action plan coming out the end, but what happened was this clear communications, this ability for people to have different discussions than they're having on a day-to-day, process-driven, governance-led area.

They started to get more spread in understanding in terms of things like value chain, what the Three Ways were, what constraint analysis fed into this piece.

But it's still a challenge. We haven't broken it yet. These things are occurring in pockets. We want it to be endemic. We want this vision of the ability to roll out system constructs on a push-button basis to serve what the business needs at the highest possible rate of speed. We've still got a part of a journey to go, but we're even having successes with third parties.

A great example from our side is we gave one of our third parties our build standards. We gave them all the rules, tools, checks, but then we said, "Actually, guys, unless you meet that, when you send it in the door, we're going to automatically reject it. We're not even going to look at it. We'll let our systems do it for us."

You can understand the contractual behaviors with that one. It was interesting. But we got over the hurdles. It worked through. Our third parties started to get it. We had a great point when we had a production issue. Between the point of having a phone call and getting something in our UAT system with no hands-on, we had about 20 minutes. Bang, and it was through. All through the automated systems, but also through the change of behaviors of not only us, but the people we worked with.

So we're not there yet, but it's still pockets.

Where are we today? Well, today, we still have change and run. But as a move on the culture, on a behavioral basis, our build guys, our Dev Services team, so the Unix, Microsoft, DBAs, middleware, have moved back into the run arena. The idea is this collaboration of that level will keep a cycle and iteration running. Our tools have grown, these things that have enabled these things to happen.

So, interesting journey.

If I dive in a little bit into background of it, I won't dwell too much, but what did we use? The key thing, the questions we tried to answer were the usual: what, why, how, when, where? What tools fit that criteria to understand why we're changing something, what we're changing, how it's being changed, where is it being changed?

One of my favorite small pieces on there is around Sonar code analysis. Our security guys came along and said, "Do you mind if we buy the OWASP plugin?" Little did I know the fun that would cause.

Next thing, you've got OWASP risk factors popping up on developers' static code analysis toolset, and security coming along and saying, "You're not delivering that." Interesting challenge.

But the nice touch is the tool then told you why you couldn't deliver that, what it meant, how you fixed it. Next thing we know, we've got systems in some areas that previously had repeat external penetration tests, and you all know how much each of those cost. They got through first time.

Hold on a moment. We'd stuck God knows how many thousands in the budget. They've done it once?

But it's another one of those great stories that says, "Okay, guys. We've given you the tool. Here's the ability to change how you operate, how you behave, how you collaborate." Wow.

So we've extended that stuff up. Automated testing is going in spurts. We have a test team that are working through tools and technologies. There's some great stuff happening around mobile testing on our side.

Splunk snuck its way in the door when we did claims. I almost got shot for that one. But it's now growing. Everybody's understanding the concept of log aggregation.

Now, it's not my final slide, but one of the things that Gene was asking about is, okay, what are we trying to work out? What are we trying to understand? Well, actually, all this stuff is quite also disparate. It's split. How do we orchestrate it? Or do we choreograph it? How does this thing hook together? What do we need to do to achieve that?

It's a key piece that says, okay, we've now got multiple people pushing buttons and automation stuff. Actually, how do we take away a lot of that button pushing? How do we put the gates and control and mechanisms to share and enable this stuff, and enhance and extend?

Oh, I've got zeros flashing. I'm sure they'll throw me off when they're ready.

But I'm getting to play next week. We've got a Docker trial we're going to look at. Will that containerization work for us? But we're also looking how do we bring security testing back earlier into the SDLC. So it's really a key piece.

I will add quickly on that slide, we even delved into database provisioning. We've tried out Delphix. We originally had a five-day turnaround to get a new database on the server. Multiple teams, multiple handoffs. Currently, we can do that inside half a day, given it's a ticketed system and it's a handoff. And next step is self-service for data provision, which is fantastic.

But the numbers are telling us things. We've got a decrease in resource needs for releases. We haven't got guys sitting there as much at 2:00 in the morning doing manual scripts to release. Our times are down by 85%. Our quality's increasing. Code analysis is reducing security issues.

WebLogic one's a great one. The team did that themselves. Three hours down to 20 minutes to create one. But when they go to the PMs and say, "Actually, you've got to shorten your plan. You wanted 20 of those things built. We did them yesterday. So actually, can we just wander off for the next two weeks because we're done?"

But the big piece: time to market. The value chain behind all of this, the time to market that we're achieving, has taken things that were previously quarterly releases. We're now doing them fortnightly. Some even weekly.

We haven't made twice the volume. We're at 1.6. But our quality markers are working. As I said earlier, push is turning into pull. People are adopting practice to drive their behavioral changes. We've even got some that have reorganized as feature teams. They're bridging across siloed areas. They are creating their own pods of work, their own DevOps capability and culture. It's still growing and learning, but it is adapting.

Ideas are flowing in the company, not led by this, but led by behavioral change as they understand things like fast track. We've got innovation labs popping up, being supported by the exec. We've got communities evolving across PMs, BAs, ops, dev. These things are growing not only because of tooling, but because our understanding of the behaviors in the market and the things that people are professing about DevOps and changing behaviors.

So as I've run over loads of times: right skill sets, right behaviors, right mindset. You can knock weeks off plans with some of this stuff. You can get people talking. You can create cross-functional capability. Large programs, the one I started on, an enormous program, can use cross-functional skilling to enhance their discipline.

And possibly my favorite slide of the whole piece, when I look at benefits, I won't hold claim to anything in relation to the P1 and P2 incident marker. I know I've helped on the cumulative releases.

But over last year, 1.6 times the number of releases from 2014 to 2015. We're keeping pace in 2016, but I know there's a lot of projects coming.

From 2011 to 2016, if you just look at that P1, P2 incident curve, that's not automation. That's people. That's quality drivers, that's leadership, that's capability that's growing to enable us to hit something recently. And I did love the way our exec celebrated it. In the fact that we went 50 days without a P1, and they sent us around a massive load of doughnuts, mainly because they're zeros. A little hole in the middle.

So, being prompted out, key lines from myself to finish off with. Problems are an opportunity. You do need this stamina to keep going. But just remember, DevOps is people. It will get us going.

Thank you.