Sure. As you can tell by looking at me DevOps is a contact sport. No, actually I lost a battle with a handrail the other night coming out of a restaurant.
My current role is build technology leader at Nationwide Insurance. It’s kind of changed since we’ve been looking at things from a DevOps perspective. So I am kind of like the product owner for our tool chain across the delivery value stream, trying to drive some DevOps practices, things like continuous delivery and the like.
2. How and when did you first hear about DevOps?
Probably about four years ago. About eight years ago we started an Agile transformation, which has gone very well, we have over two hundred Agile teams. About four years ago I started to hear the word DevOps. It wasn’t quite clear what it meant, but it sounded like something that was worth pursuing.
3. How did DevOps get started in your organization? What were the first steps that you took?
As we started to learn about DevOps we realized we were already doing things from a DevOps perspective, we really just weren’t calling it DevOps. We had a strong Agile foundation, we had a strong Lean foundation, my boss, Tom Paider, is actually publishing a book next month with Mike Orzen about “Lean IT Field Guide”. I think I got it right or... I’ll get in trouble.
But we haven’t really looked at it holistically, it was still more like: ok, we need a new deployment tool, we need a new release tool. We've started to think - using concepts like value stream - about how do we look across the value stream and figure out how to put these things together and integrate them in a better way.
Yes. We started out taking advantage of current initiatives. One of the first initiatives that we had was that we knew we wanted to upgrade our release tooling, our deployment tooling and even going all the way back to the release planning of the work intake process. And it wasn’t just the tooling. You’ve heard a lot in the conference that there’s culture, there’s process, technology and organization change aren’t going to magically make you better.
We were able to take advantage of existing initiatives and say: in the old way of thinking we have three silos, we would have come up with three tools, we want them to work together, it would have been more costly. Let’s figure out one integrated tool suit, or one where we can integrate tools to provide a capability. That started to demonstrate some value, and then in the last year it has really accelerated.
When I gave my talk last year I still think there was this feeling of “Do we really need to go faster? Where is the sense of urgency?”, but you can really tell the difference between last year and this year. In all the talks people are talking lean concepts, they're talking about reducing lead time. People weren’t talking that way last year. So I think that has helped influence our CIOs to realize that this is actually part of a different model and a way of delivery.
Right. So we started with a DevOps CoP [Community of Practice] about a year and a half, two years ago. Just to bring together infrastructure folks - we have an IT for IT area - and even folks like architects, even people like portfolio planners and release managers. We'd talk through some of these things, and one of the questions that we would get is what’s the link between Lean and Agile and DevOps? And what’s this two speed or bi-motor IT? (I just look at it as variable speed accelerator delivery - you want to go faster).
That lead us to having a more consistent story, across the way we presented it. That then allowed us to go to executives with a consistent view. So if they talked to Carmen and they talked to Rich and they talked to Cindy, they weren’t hearing three different stories. They were hearing one story and that allowed us to get some traction, to say we need to manage this in a more holistic way to really drive improvement across the enterprise.
6. Which initiatives are you currently undertaking? Do any of those involve organizational change?
Some of the initiatives we have going on right now are things you’ve heard at the conference too, things like more self service in infrastructure. We already do a good job with some of the Agile practices, test automation. Continuous delivery is a big initiative that we’re driving.
We’ve done some Lean work in the past so we are starting to apply that. We’ll look at all three components: there’s a people component, there’s a process component and then obviously there’s a technology component. I expect that we’ll be driving things across those three components moving forward and making changes based on what makes sense in order to become more effective and more efficient.
Because we already had a centralized capability organization, I think we are ahead of the game. A lot of different areas I’ve talked to in the past didn’t have that and so one of the things I talk about is that to automate anything, you need patterns. And to be able to create patterns, you have to reduce variants. So we were able to start to talk across the enterprise.
If you are going to do things like continuous delivery and you have dependencies like we do - we have twenty business areas – and the majority of initiatives that a business area has and gets funded for is going to impact systems that are in other areas. Then if you just take this narrow approach “I’m just going to manage my funded work, my portfolio, my deployments”, that’s not going to cut it because you have all these other dependencies with other areas.
We sell the concept of, in order to get the true continuous delivery and visibility, you can’t have people opting in and opting out. It’s like a link in a chain opting out, well then you don’t have a chain, right? We are having effect there and essentially we are in a position where I could just say, gently or in various ways, that we are replacing this with that. The thing you are using now for deploys is not going to be there anymore, so you got to get going. Now hopefully that’s not the only reason they are doing it. They see the value, it makes sense to them, they want to get involved. And we have a lot of people who want to get involved and want to go first but you have all that organizational change, the kind of things that Paula Thrasher was talking about today, they just have to deal with.
Yes. Some of the advantages we had is, again eight years ago we started Agile and people were saying: “Oh, this is going to be the wild wild west, it’s going to be crazy”, and we actually demonstrated that you could balance innovation and discipline. I worked for Bell Labs before I came to Nationwide and Bell Labs, at its peak, was very innovative, going back to the transistor and Unix and all kinds of things, many patents a day. But there was also a discipline, if you were doing software development it was like in the air, you didn’t even have to have a document. You just knew there were certain ways you were going to do things.
We went through some of that shock with Agile, I mean we were changing the furniture, so the whole transformation of building floors on buildings differently or transforming them was different. That made it easier because we’d seen this, but I think with DevOps there’s still some cultural change.
One cultural change is moving from “I’m going to release on a schedule basis” to “I’m going to release when I’m ready”. Another cultural change is a lot of central governance in saying “We want more self service capability, we want the business areas to be able to go as fast as they need to go”, but still maintain some discipline in what we are doing. There’s still going to be quality criteria. We have very high quality today, we don’t intend to compromise that. We want to maintain that but we want to provide the business ways to go faster and be more efficient.
So there is still culture change but I think it’s easier if you already had that continuous improvement, that continuous learning culture which we had already cultivated over the past five or six years.
9. What have been the greatest achievements, and failures as well, in your journey so far?
The achievements are taking things that used to be just Carmen's wild ideas – and it’s not just me, there’s a whole team of people and there’s a whole Nationwide culture, I’m sort of just speaking in general terms - but some of these ideas that we had, that were just a PowerPoint, and then we could start to demonstrate them. It’s one thing to go and give a talk and it’s another thing when you can actually go from “Here is work intake from our portfolio planning system, here it's going to be scheduled, here is code being built, here it’s going to be deployed to an environment and here it’s going into production, or simulated production”. Somebody in my team can demonstrate that in thirty minutes rather than me giving a two hour talk, that’s very powerful. You can show that to executives.
The failures... We’re doing an experiment. It’s kind of funny because as you’re delivering continuous delivery, you don’t want to do it in a waterfall way. So people would say: what’s our requirement? Well you can’t really go and elicit a future state vision from the people who are working in current state. They are going to give you requirements for what they do today that's maybe a little better. If you really have a vision of a future state that’s much different, you are not going to get those requirements. You are going to say: this is where we are trying to go, here are some principles, we are going to experiment, we are going to get results and we are going to try to drive that.
People would probably say we should be going faster. From an organizational change perspective, you learn things in terms of how you get the messaging out around this right and get people to see more of the value that they are going to get out of it. Because sometimes you see it, but trying to translate that future state in what you think it could be to people in their current state, that’s something that we can probably do a better job of.
Clearly we have concrete examples of the Agile work we did, in terms of improvements in delivery, productivity, quality, availability, things like that. We had demonstrated results from what we did in Agile and what we are trying to do now is say: Agile is only one part of the value stream and we want to stretch that out,trying to move more frequently.
We have areas for example that do some of the tests and learn things, the AB kind of testing that we’ve talked about and we have seen value there. For example, you want to try a different way, a different web experience to see if it sells more policies. Well, this is the way we present the information to a potential customer today. If we change this, what does that do? Do we actually get more sales online, do we get less sales online? Those kind of business cases that people were already doing on their own that we were never involved with.
Some of the use cases are this kind of things, because in order to do that, they had to get exceptions to everything. Because they were doing everything outside the process, and why is that? This IS the process, this is what we want to enable. They know better than we do how fast they want to go and how much data they need to collect.
Those kinds of use cases help drive some of the feeling of wanting to make this a standard way for people to do what they need to do, based on what their business needs are.
11. What kind of metrics or feedback are you collecting to validate the value of these transformations?
That’s probably something we need a little more work on. Obviously we have very good metrics on quality, availability. One metric we don’t have really is lead time.
We sort of have this process at the end that slows things down in order to make sure everything on the checklist is done and then it allows you to release. One of the graphs this morning showed that if you have this big process at the end that is slowing everything down then you don't truly know what your lead time is because it's not based on activity anymore. It's based on: we're going to do this, we’re going to wait until this calendar day in order to deliver. So one of the things we need to do is probably do more value stream analysis, understand more what those current lead times are. And then baseline that and see how we can optimize.
Another metric we are looking at is deployments. We know that, if you are going to deploy more frequently in production, you have to be able to deploy more frequently through your pipeline. You are never really going to deploy more frequently into production than you can into a dev or integration test environment. So we are starting to baseline those measurements. As we're starting to do this I would expect to see more frequent delivery into those test environments and that would set us up then for more frequent delivery into production.
12. My final question is about which challenges or roadblocks do you have ahead in your journey?
I think there are always going to be challenges when you are trying to do things. Somebody tweeted out "We're asking difficult questions not to be difficult but to make things better". So there's going to be challenges, as part of the culture change. You just have to be better with knowing how to address those and really sort of navigating your way through it. Because it is about, again moving people from a fixed mindset to an adaptive mindset, and driving more continuous improvements.
The challenges are really never going to end because when the challenge is over that probably means the journey is over. There is a famous quote from Toyota where in a stand-up one of the senior managers said: "Is there any problem?" and the managers were always saying there's no problems, and after a while he goes "Well if there's no problems we don't need managers. I can just fire you”. You are always going to have those challenges, it's not necessarily always going to be technology. You can probably solve your technology challenges, it's the cultural challenges that you have to continue to drive as part of continuous improvement.
Manuel: Thank you very much Carmen.
Thanks Manuel, I've enjoyed it.