Carmen DeArdo

Hi, everybody. Having fun?

That's going to end, if you are.

I am going to start with a grievance. Gene was talking about people and promotions and things. I'm saying, "Gene, you didn't come through for me here, Gene." Yeah. If anybody who saw me last year says, "Carmen, you're lucky you have a job anywhere in IT."

So anyway, let's talk about Nationwide. Enough about me.

Nationwide: a lot of products, Fortune 100 company, one of the best 100 companies to work for. Lots of different things. Peyton Manning, you know the rest.

IT, we actually have over 9,000 IT professionals. We have 20 individual units. "Individual" is probably not a good word when you're talking about DevOps, but there are 20 business-facing IT units, and that will come into play as we get into the talk.

The story. Our story is we started about eight years ago with what I would call an experiment in Agile. We started out with a handful of teams, and we wanted to see if we could really make Agile work at scale. It really was a question, in some ways, of survival, because there was a lot of pressure to outsource. The idea was, we have to be able to demonstrate to our board that we can actually be competitive and do this thing. And the experiment was successful.

Today we have over 200 teams. We do almost 70% of our work through Agile teams, and that will be 100% probably within the next couple of years.

So the results are so far so good, right? With quality, productivity, availability, delivery, we got good results out of this. So it seems like we should be able to declare victory and move on, but actually it's really just the beginning of the story.

So what I'm going to talk to you about is our journey, where it stands today. We certainly aren't experts in what we're trying to do here. We don't have this down. We're trying to understand as we go. So one of the reasons I like to talk is you get a lot of people to give you feedback. So this is a great opportunity to see what we're doing and try to help us get better at it.

If you actually look at where we are, probably about three years ago, four years ago, we started to take a step back and said, "Okay, we got this Agile thing going pretty well at scale." But when you think about it and you start to think more about lean and the value stream, which are things we weren't even saying, wasn't in our vocabulary eight years ago, what we really had done was optimize the middle of the value stream.

Now, it's not like the CIO woke up one day eight years ago and said, "I got a great idea. We're going to optimize the middle of the value stream." Right? That's not how it happened. We started like a lot of companies with Agile and trying to get better around design, develop, and test.

But what we found was that we really only solved part of the problem. We can go very quickly through the middle of this process. Once a story hits our backlog, all the way through the iterations to where we mark it complete, it goes very quickly. We have good visual system management. We have good lean principles.

However, on the front end, we have an issue with starvation and flowing work into the teams. Many times our Agile teams are waiting for work, which is a form of waste. You're wasting your most important resource: your people.

And then downstream, delivery slowed down. So when it goes through that last iteration, it's not like it was going right into production. There was a lot of manual and what we call high-ceremony processes that were slowing down the actual delivery of value to our customer.

So the challenge then is, how do we address that? How do we go fast across the whole value stream?

So we had to take a closer look then at what's really happening here. What are some of the inhibitors to lean delivery?

By far, and I think you heard some of this this morning about it's not about the technology, by far the biggest challenge that we have and the most battle scars I probably have is around work variance. We have 20 different areas that, at one time, things like life insurance, homeowners insurance, auto insurance, pet insurance, retirement plans, the bank, these areas all sort of function as their own IT component. We didn't have a concept of one IT. We started to address that, but we still have lots of variance in our processes, and you can't really apply good technology when you have a lot of variance in your process.

So work variance, and I'll get into that a little more, is really an inhibitor to lean delivery.

Annual planning, right? So we talked about the flow. Well, one of the problems with flow, or the source of flow, is we do an annual funding planning cycle. Well, that doesn't help us get continuous flow or continuous work into the process. So how do you start to address that with the business? I'll talk about that, although that's still an area that really I think we need help with. So I'm open for suggestions there.

Redundant sources and systems. So when you start to look at your value chain, you realize nobody really was probably responsible for that end-to-end value chain. What are the systems you're using? What's your source of record? I'll talk about that a little more, but you end up finding there's a lot of waste in that space too.

I talk to other customers around Columbus and other companies. One company has five defect management systems. Well, you're not getting value by having five different defect management systems. So how do you get rid of some of that non-value-added variance?

Dependencies and wait states. If you go to an Agile team and you say, "Why can't you go faster? Why can't you deliver faster?" you're going to get reasons of they're waiting for something. They're waiting for work. They're waiting for other teams. They're waiting for environments. They're waiting. It's not like the actual value they're adding is taking it so long. When you actually do the analysis, what you find out is there's lots of wait states there.

Lack of integration. And again, because you have all this variance, you also don't have a good integration. And this feeds into the lack of visibility.

So if you actually think about it, if you're in an Agile work setting, you can go to Gemba. You can go and see the work. You can see it in the backlog. You can see the flow. Visual system management's a beautiful thing.

But if you actually think about it from the actual beginning of when someone has a business idea all the way through the deployment, how do you see that? It's in different systems. You have a portfolio management system. You have a project management system. You may have an Agile work management system. Who knows what tool you're using for release planning? There's spreadsheets, deployment scripts. It's impossible to follow that work through the process.

And sometimes I use the analogy of, it's like trying to coach a basketball team and you don't get to watch the game. You sit in the locker room, and a manager comes and just gives you scores and things, and then after the game, it's like, "Well, go coach them now." It's like, I didn't even see the game. But who's really seeing the game here?

So it shouldn't really be a shock when projects seem to be going well and go off track, because we're really not seeing the work as it progresses.

Manual activities, probably don't have to say a lot about that.

And then I think the last point, in a way, might be the most important. Throughout this conference, you're going to hear a lot of smart people talk about great practices: automated testing, continuous integration, automated deployment, infrastructure automation, self-service, which is another theme I think you're hearing this week about self-service.

But even if we were perfect, even if we optimized all those things, we're still spending the majority of our time before a single card gets into the backlog of an Agile team. And I don't think we're probably alone there. So I'm not saying those other things aren't important. They are critical, but it doesn't seem like this is part of the problem that many people are looking at.

If you cannot flow the work effectively into these teams, then we're continually going to be addressing this problem of that part of the lead time. The world doesn't start when you do a build. It starts when the customer has something that they want, and you deliver it to them. And that part of the process is something I know that we struggle with.

So, just looking at the clock here.

I'm going to talk a little bit about our continuous delivery pipeline. Later I'll talk about our DevOps framework. Continuous delivery obviously is a key part of that.

Going back to The Phoenix Project, which I know we've all read and are intimately familiar with, one of the things that they struggle with that Erik... I think it's Bill. Or is it Bill who's kind of the main character? But Erik is the lean guru, keeps asking the question, "What types of work do you have? What types of work?" And it's like stumbling around.

So who can name the four types of work from The Phoenix Project? Just yell it out. I know you read it. If not, Gene's really going to be upset.

Projects. Projects. Business value work. So there's business value work.

Changes. Changes.

Operations. Yeah, I'll call it operations work.

And then the last one that they struggled with for a long time was the last one that he found. I know you know it.

Unplanned work. Unplanned work. Right. Very good.

So that's your source of work. So if you start to think about this, I should be able to have a system of record for that work, and I should be able to automate bringing that work into my continuous delivery pipeline. It sounds like a simple concept, but it's not.

In our case, Clarity is where our business work comes, and everybody does use Clarity, but we're very ingenious in our different ways to use the same tool the same way. So Clarity's where our business value work comes from. ServiceNow is where the operations change work comes from. So in our case, that's where you want to feed that operations work. And then Quality Center is where the defects come in.

So when we built this, we spent a lot of time identifying and trying to... One of the things, if you do any kind of lean training, you're going to start with is, what's your work intake? If you talk to a team and they don't have a standard work intake process, and they can't explain how they get their work, that's going to be the first problem area because it's kind of like garbage in, garbage out. How do you even start in here?

So we used Tasktop technology to bring that work into Rational Team Concert, where we schedule what we call the application or the operational changes. So this is work that is scoped for a given initiative that can fit within a release.

And it's very important that each area, there can only be one funded initiative. So I have talks with the portfolio leaders, and it's like, okay, here's an initiative. And then it's like, "Well, I create my own initiative." It's like, "Why?" "Well, I have my own initiative. I have a child initiative." That's not going to work, guys. There's one funded initiative that comes in and you attach changes to.

Now, those changes then can also be associated with the Agile work you're doing. So now you have visibility of the work coming in, where it's being scheduled, and where it ties into the Agile work that you're doing.

And then that moves into UrbanCode Release, where we start to bring in other information, also through some integrations. So we can start to bring in, well, I already talked about the defects, but we can bring in things like security scans. That's part of what you're going to use to certify your release. Test results, other things that you may want to use that would help you certify or potentially automate your deployment activities.

And then you have visibility all the way through deployment, where now you know the code gets built, it goes through environments, your pipeline is very visible to people, you understand what version of code has been in what environment. You can set up quality gates or certifications, which could be manual or, when you get more mature than we are, automated. And then eventually it gets deployed.

Now, as I said, the technology itself is not going to solve all your problems. But in order to implement something like this, it will force you to address a lot of the issues that I talked about in terms of flow, in terms of integration, in terms of sources of record, and some of the variance that you identified as getting in the way in your value stream.

So one of our goals, and one of the elements you deal with from a culture side, is we want to empower, and when I say the business here, I'm really talking about those business-facing IT areas.

What we really want to do is move from a model that we currently have, which has a large central federation. So we have a process that has grown that said, in order to get this process under control, we're going to centralize it. We're going to slow things down to make sure everybody can get through and we can have quality deliveries, which we've accomplished.

But what we didn't do when we got to that point, then you have to move back and shift the focus back to the business and say, let's allow the business to go faster. Let's allow them to be able to deliver faster.

So what goes into that?

First of all, it's providing automation. So what I tell release managers is, if I can give you better information, up-to-date information on defects, on performance, on security, you're going to be able to go faster. And so automating that information so that you have real-time information, that gives you more certainty in what you're dealing with in order to accelerate your release.

Visualize. So again, the whole part of continuous delivery and continuous visibility. We want to give more information, again, to allow the business the visibility and control to drive at a much faster pace.

Sometimes I don't use the football analogies that the one guy used. But sometimes I use the Autobahn analogy here, and I say, the way we've done this in the past is, if I'm building the Autobahn, I'm not telling you how fast you have to drive.

In the past, what we would have said is, okay, if there's a van of kids and they can only go safely 40 miles an hour, nobody's going more than 40. That's it, because then we know everybody will get to their destination safely. But what we're saying now is, look, if you need to move slowly, if you have a highly regulated project, if it's very complicated, that's fine. But if you need to go fast and you know how to drive fast, then you should be able to go as fast as you need to.

So this is why I like more the aspect of multi-speed or variable-speed IT. It's really not two speeds. It's not like I drive in the city or I drive on the highway. You drive as fast as you need to when you need to, based on your own capabilities.

And my goal is to provide that process and technology solution to those business areas and then get out of their way. So if you're moving slowly because you have a lot of high-ceremony processes or you don't have a lot of automation, well then, that's up to you to address.

But there's other areas that are going to automate and are going to get quicker and are going to be lean, and they're going to go a lot faster, and that's going to drive the culture.

Trust. A lot of the issue with trust is not necessarily... I sort of like that offense, defense kind of picture that we had today. I've also heard it sort of like, the developers don't want to miss the boat, and the ops people don't want to sink the ship.

But it's not really, I don't trust Joe, and yeah, it's good if you go and you get to meet Joe. But even if I had people who ate lunch every day, they still wouldn't let that guy move anything into production, believe me. Because it was about, I own the tool, I govern the tool, I own the product. I own it. I deal with that in a lot of our infrastructure areas.

And it's like, okay, let's think about this a second. Yes, you own the tool, but I have people here that own the requirements management tool. And you know what? They are not experts in requirements management, and furthermore, if someone produces crappy requirements, they don't really feel responsible for it. So why do you feel responsible for what they're deploying? You're providing the tool, right?

We have to empower the areas by giving them better capabilities to take accountability for what they're delivering. And that's a big issue, and I understand where it comes from, because they were the ones getting the 3:00 a.m. phone calls. They were the ones that were, "My deployment didn't work," and, "Production's down." So that culture has to change, but we have to also let that go so that the business areas can take accountability and drive this.

And then it comes down to empowerment, which is what I've been saying. Let them decide. They know the risk. They know what they're trying to deliver. They know the market needs. Let them go. Let them determine. They can determine how fast they progress through these environments.

Now, another question I get is, well, this is going to be the Wild Wild West, right? You're going to let people just go. There's no separation of concern, separation of duties. And I say, "Well, that's not the case." The path to production is still based on quality criteria.

And actually what we're saying is, you determine that. That's a quality assurance function. You determine what that criteria is. It's actually more visible now than it's ever been. You can set up quality gates within the tools.

And then it's up to whether that software, that version, has to be built, and there has to be a version that can go through all the different environments to get that criteria. And it can be automated. It can be manual. It could be hybrid. It doesn't really matter.

But it will determine based on its own quality whether it's ready to be released or not, not based on anybody making any other decision. It's either it meets the criteria or it doesn't. So we're not sacrificing quality, performance, security, usability. We're just making it all much more visible and much more transparent and giving people the ability to automate it.

So again, sort of a summary of what we're trying to do from this perspective is we can bring in a lot of the information into the solution: the quality, security, test status. We provide different views, so if you own an initiative now, you can see that view of the initiative across all the different changes.

So we have some initiatives that maybe three or four different areas have to contribute to. You can now see that. It's not in five different spreadsheets. Dependencies and impacts, deployment status.

And then the other thing that I really didn't talk about is delivery opportunities. By making this now more visible all the way to the portfolio level, the portfolio managers actually can see what's in releases and when they have opportunities to actually get work done.

In the past, we weren't able to make that connection. There was no connection between the backlog of an Agile team and what was being planned in the business areas. Now there's opportunities to say, "You have releases here where you have opportunities to deliver." So you can take advantage of those things and try to, again, change the culture of people looking for opportunities to deliver more quickly.

Here's kind of our foundational model.

So on the bottom, you'll recognize kind of the Three Ways from Gene Kim's The Phoenix Project. And then there's a set of practices. They really shouldn't be a surprise to anybody. Some of these things we're more mature on. Other things we need some work.

The whole idea of automate infrastructure, this self-service, I think that's a theme you heard today. We have to provide more self-service infrastructure. Anything that's a request-response with an SLA is a wait state in your value stream. How do you clean that up?

Now, on the other side, on the culture side, we have to reduce some of the variance and some of the patterns that we're asking infrastructure to automate. If everything is a snowflake, you can't automate that. So there's a contract here that says, how can I find those patterns? How can I reduce the variance so that I can actually go and automate some of that?

But then I really think a lot of, again, issues are on the culture, or challenges are on the culture side. I've talked through some of these. You've heard some of these in other talks. The technology without the culture, again, is not really going to solve your problems or our problems.

So people will say, "Well, how do you do this, and where do I start?" This is not really how we started eight years ago, but this is what I say. Once you realize this is what you want to do, you really want to map this to your value stream, prioritize your work, experiment. You have to experiment. You have to have this model line concept where you try it out, see if it works, allow yourself to fail, and then improve it. It's going through that whole Shewhart cycle, Deming, plan-do-check-act.

Look for integration opportunities.

Holistic funding. Funding can be an issue because the way we funded things before was based on somebody's idea for a single optimization. So I want to do this, or I want to do that. Well, it's not that those were necessarily bad ideas, but are we really sure we're improving what's our bottleneck? Or what we think is in the top three of our bottleneck?

If we're not really funding this more holistically to say, "Hey, we have a team here who's looking at the value stream and prioritizing. If you fund us, we can prioritize and be empowered to start to do this." We shouldn't have to send 10 initiatives up to some executive steering committee to see how many of them they'll actually fund. That's not looking at this from a holistic perspective.

And then again, it comes down to empowerment. Do you really have a team who feels like they're empowered to make this happen across your whole delivery value chain?

So final five thoughts. The break's coming, hold on.

One is, you have to think horizontally. The more you talk to people, you realize they're in their silos. They don't really understand where they fit into the value chain.

I talked to some of the portfolio coordinators about what they do, and I say, "Well, okay, then how is that actually going to work and actually get into the Agile teams?" And it's like, "Well, I don't know. That's somewhere else." Well, it's all part of the value chain.

I gave a talk to infrastructure and they said, "Oh, that was good," but they didn't really understand how they fit into it. It's like, folks, and I don't blame anybody, it's just the culture. We haven't thought about how we fit into this end-to-end process.

Local optimization, in many ways, is the enemy of lean delivery. If you're optimizing something that's before your bottleneck, then you're creating more inventory that's just going to build up. If you optimize something after your bottleneck, well, then you're creating more wait states for what was already downstream waiting for work.

So that's not to say you can only do one thing at once, or you can't do some things knowing it's going to help you in the long run. But you have to be careful that you don't have a bunch of work in progress that you're really not managing, that you're really sure how it's going to affect your end-to-end delivery capability.

I sort of already alluded to this: automation requires patterns, and patterns require eliminating variance.

And again, I sort of said this before, it's hard to manage what you can't see or measure. We didn't even have a measure of lead time, so how would we know what it was to improve it? Again, more of the horizontal thinking.

And finally, technology, in my mind, is really the fun part. It's the culture that's the hard part that it really takes to get this right.

And so finally, just like last year, need lots of help.

I think we struggle with investing really in that whole value stream enterprise architecture. Sometimes it's like, well, who owns that? Does anybody own it? Well, I own a tool, or I own this, or I own that. I'm the product owner, actually, for everything in the value stream.

But a lot of these things, we don't do the same care and feeding to our delivery capability as we do to our business applications. Do we put our best people on this? If you have a really good architect, do you put them on the highest priority business work, or do you have them work on improving our delivery capability? I think that's a culture element that I see.

Again, managing that work in progress. Are we really managing the work in progress that's going to drive this continuous improvement of our delivery capability?

The self-service culture, I think we've talked about that, but I think I could still use some help. I talked to a guy at lunch from Fidelity, and I think they're doing some great stuff there, and I'd like to learn from them.

This creating an Agile business planning culture. Eventually, you do have to get into the business to allow that continuous flow of work.

And then, it's ending, and I know this is kind of something, we talk about people, and I know why Gene's doing this and Damon and other folks, is around the work experience for people. And especially when you talk about people who are trying to improve this, which are disruptive activities.

The people who report to me, sometimes, they're engaged, but they're not always having a fun time. They're the ones asking the five whys and trying to drive the variance out, and they need a lot of support because this is not easy to do. And you may not win a lot of accolades when you're first trying to do this because you're trying to drive some change, and you're trying to ask difficult questions, not to be difficult, but to make everybody's life better.

And with that, thank you.