Kevin Fisher - DevOps Enterprise Summit 2018

Kevin Fisher, Nationwide Insurance Associate Vice President, Lean Process Management (Lean, Agile, DevOps) sat down with Bob at the DevOps Enterprise Summit 2018.

Connect with Bob on Twitter.

Transcript

Bob Payne:  "The Agile Toolkit."

[music]

Bob:  Hi. I'm your host, Bob Payne. I'm here at the DevOps Enterprise Summit 2018 and I'm here with Kevin Fisher from Nationwide. Kevin, we worked together an awfully long time, back from the early days of Agile, at Nationwide.

I remember, actually I Tweeted, because it was in the talk with a couple of gentlemen that were from Nationwide. They were talking about the DevOps roll out that they're doing and they had this sort of Sherpa chart.

It's always great to see how far you guys have come from the early days. I was impressed by their talk. Unfortunately, I didn't get to your talk, but I hear you had some pretty interesting things in your talk around metrics, and measuring flow, and that sort of thing.

Maybe we can chat about that?

Kevin Fisher:  That's right, Bob. Bob and I worked together back in 2008 when we experimented with Scrum and XP. Bob and some other folks were our on‑site coaches.

From those early days of having one Agile team, now we have 200 Agile teams. All of our work is done with those 200 teams. We think of our transformation in three distinct kind of bodies of work.

The first one, obviously, is introducing Scrum and XP and then scaling that up. That took a long time, given our size of our organization. Now we're focusing on DevOps. You heard the talk from Jared and Jim. We're rolling out DevOps in a self‑service way. It's more carrot than stick.

Bob:  It was great to hear, because all too often it is not implemented in a self‑service way.

Kevin:  We want teams to figure out their local impediments and use these techniques to solve their local processing problems.

We gamified the friendly competition between teams. We have a monthly DevOps challenge. All the teams can submit their progress against whatever that topic is of that particular month. We choose a winner, and they get custom stickers for their laptops. That's it. There's no monetary conversation.

[laughter]

Kevin:  When we were exploring and doing some experiments, we had two of our teams have a friendly competition against each other, and it was simple. We didn't give them extra time. They had to complete all their normal standard work.

We said, "What can you do to go faster and get your work done faster? By the way, you have a colleague team over here that we asked the same challenge. We want you to attend each other's show‑and‑tells."

It was fantastic to see the friendly competition in their eyes when they're attending their colleagues' show‑and‑tell and the colleagues talking about how they just pruned 2,000 automated tests that weren't delivering a whole lot of value to 700.

Now they have it integrated into their build process. They feel real good about it. They have a big visible monitor that displays the health of the build on a real timestamp. Then you can see the other team thinking, "Wow! We could do that. We could beat that."

It was very healthy, and that's how we came up with the idea. Then, when we heard about the Verizon cup...Verizon has a similar program, and we said, "That is a fantastic idea. We're going to leverage that idea from the Verizon cup. We're not going to make it quite as elaborate ‑‑ they actually give a trophy. We're going to scale it down and just give stickers," and it's been a great thing.

Then the third avenue for us is this whole concept around changing the mentality of our senior executives in finance, from project to product. That's a difficult turn to make.

Bob:  It's a huge turn. Yep.

Kevin:  We've had many conversations over the years. We've made some changes in IT that are putting us in the right direction, but we can't go further without the business being side by side with us.

Early on, attempts at forging that conversation with our business executives and the finance teams was not received well, because we kept talking in IT terms.

We want to bring Agile, we want to infuse Agile methods into our planning. We want to talk about this. We want to talk about that. They rejected a lot of that conversation because it was viewed as very IT‑centric, and just not in terms they could understand.

The progress we've made on two fronts over the last couple of months is number one, we now have a very rudimentary view of lead time and cycle time within the functions of IT.

It's not perfect. It's certainly fraught...You could poke holes in it if you look real hard at it. But, when we boil it up at the macro level, the law of large numbers takes hold and we actually feel like yeah, this directionally correct enough.

It shows what we knew all along and that's the development piece of hands on keyboard, writing code, is not the problem. That's actually the shortest piece of our value chain.

Bob:  By a ridiculous amount.

Kevin:  By a ridiculous amount. Two and a half percent of the time we spend on stuff is actually on hands‑on‑keyboard coding.

Bob:  That must have been validating but also a head‑scratcher. I'm sure you took a look to make sure you've got the numbers right because that seems like something that's very...

Kevin:  We have the numbers. It's very low.

Bob:  People would want to poke a hole in.

Kevin:  People want to poke a hole in it. It's a very large data set so, "All right. Let's say we're off by a 100 percent." It's still pretty low.

Bob:  Five percent.

[laughter]

Kevin:  We still have a huge opportunity space after the development is complete and, obviously, well before the development happens. Now we're really focused. It gives us data to have ammunition with the people that are either dragging their feet on DevOps and CICD.

We can say, "No, no, no. Here's the data. We need to improve this. You need to show measurable improvement." Then it also helps us in those conversations with our business partners to say, "Look. This business‑IT relationship is really super important and perhaps we need to start thinking about things differently."

The second half of this conversation that's actually been new in the last several months is our CIOs ‑‑ we have a business unit CIO lined up with each unit business president ‑‑ have been successful talking with their business unit presidents and their cabinets, made up of SVPs and other senior leaders, and trying to get them to conceptualize a future state in small increments of time.

Historically, our company has made very large multi‑year bets, and a handful of them. We're going to spend hundreds of millions of dollars over the next five years and all this wonderful stuff will come out of it that's extremely difficult to measure. That doesn't allow us to respond to market conditions at all.

There was an impactful trip, probably similar to most companies. We've had good success getting our executives out of the building to visit with other companies. It doesn't even have to be a financial services company. It could be other industries.

Talk with peers at their same level, and learn. We used it to get progress with our IT leadership on adopting lean management techniques across how we scale. Now we've used it with other business executives to get them to think about conceptualizing outcomes in smaller increments.

I tell the story that we had a group of executives take a trip out West to visit the typical unicorns of the world, Facebook, Google, Amazon. When they were on their trip, they said, "We need to go figure out how these companies do a much better job at long‑term planning than we do." They came back...

Kevin:  Yeah. They don't do long‑term planning.

Bob:  They do strategic execution rather than strategic planning. [laughs]

Kevin:  Correct. Yes, yes. Exactly. That's what they learned. They said, "We actually don't do that. We're just much better than you at sensing and responding to market conditions." What that trip allowed the CIOs to do is introduce ‑‑ I know it sounds simple ‑‑ language that the business leaders could rally around, that they didn't view as IT language.

They didn't have an allergic reaction. When we say things like, "Small batches, iterative work," they have an allergic reaction. They're like, "You're talking IT speak. Agile, that's like an Italian term. Don't come to me with that."

Bob:  [laughs] It's a major word.

Kevin:  Yeah. [laughs] It's a major word. They don't know any of that stuff. "You're an IT folk. Don't tell me how to run my business." They have an allergic reaction to it.

When we talk about sense and respond to market conditions, we actually introduced the term called "base camp." You saw it in our DevOps mountain journey. We have base camps and just tranches of work we want you to try to achieve. Those things that we listed don't have to be done in any particular order, but they needed to be done before you move on to the next base camp.

That concept is now resonating with our senior business leaders like, "OK. You're saying that we can package up or at least conceptualize this body of work. You can get it done in a reasonable time frame, usually three, four months. We can deploy it to our end customer, whether that's the end‑customer, or a distribution partner, or what have you.

They will get value. We'll get value. We'll measure that and then we will decide whether we want to continue or pivot. It's broad concepts that are outlined in books like "The Lean Startup," by Eric Ries and others.

We are using language that our non‑tech‑savvy business leaders can rally behind and don't feel threatened by. It has been really impactful for us to get to that point.

Bob:  I was speaking earlier with a gentleman from Microsoft and they did a sort of long‑term study over the features that they had added. They found that one‑third achieved some improvement in customer experience, a third were neutral, and a third were negative.

When you that sort of data that says if we just produce the things that we will plan to do, we're at net zero impact unless we kill the losers and double down on the investment in those things that are moving the needle.

There was a huge conceptual turnaround for Microsoft. They're huge. They have a huge legacy codebase. So big, he said they actually broke Git and they became one of the major contributors to the Git source code because it was taking 12 hours to clone the Windows repository onto your laptop to make changes.

It was just so a lot bigger than the Linux kernel, a lot bigger than any other stuff that had been thrown at Git to date. They developed the new virtual file system that's used in Git and they are now down to like two to three minutes for that clone.

This idea of reacting to an emerging situation, I think is one that can resonate. I'm really interested to get my hands on the "War and Peace and IT."

Kevin:  Mark Schwartz?

Bob:  The Mark Schwartz book. I loved his analogy with the battle with Napoleon and the slow decision loop actually not even neutralizing, but making the decisions actively bad.

We have not done ourselves much good in the community to allow this idea that Agile, DevOps, the lean terms we've been using were fundamentally IT. It's good to hear that you guys are at least turning that around.

Kevin:  It's the combination of those concepts that we feel are going to give us the advantage and the power. If we only focused on making our Agile machine more efficient and implementing DevOps everywhere...

Bob:  10 or 15 percent, possibly.

Kevin:  ...it would only take it so far. Now, I will say we have an example of where...We have a particular couple of teams that support our digital online experience where customers deal us over the Web.

They are probably our most advanced example. They can deploy at will. They can do safe, reliable, zero‑downtime deployments whenever they need to, multiple times a day if necessary.

They are our business partner and they have by the way done a great job forging a very strong relationship with their business partner. After they had done this only for two or three weeks, the business partner remarked, "Well, maybe I don't have to test everything now." Like, "Yes."

Because now he has confidence that when things do arise, you can fix it right there, very quickly. Our mean time to repair is very short. That saves him time and energy, it saves us...

All good things happen when that circle gets tighter. Being able to demonstrate, not just talk the talk, but demonstrate it, you're boots on the ground with this. When we actually can achieve this, it changes the whole culture around and how to thinking around it.

Bob:  What has been an interesting thing that you've learned at the conference?

Kevin:  Focus of my talk with Nicole from Tasktop, plus many of the other talks here where they were talking about CSG, Mark Swartz's talk in the morning yesterday all around the concept of project to product, and the difficulties with that. Not a one size fits all models, not a prescriptive model, a lot of people trying to solve the same problem.

There seems to be wide agreement that whether you are approaching that from technology left or from the business process on down, you're going to uncover all sorts of complicating factors.

I was talking with Verizon just a few minutes ago and as they tried to move along their project to product journey, they might have success with a business partner rethinking how they are going to conceptualize work in a product way.

Even the roles that go along with supporting that work, thinking about the differences between what a product manager might do, and product owner, and should they be basically sourced from the same group.

All those sorts of nuances of execution. Then when they get to the supporting IT components, they figure out well, the IT components were never architected to operate this way together.

I heard similar stories from Discover Card where they've done a nice job with some of their executives on conceptualizing around products not projects, and they need to come to figure out, but even then within a product realm, they have miniature silos within IT where teams either have competing and not‑compatible technology.

[crosstalk]

Bob:  Business intelligence team. So many components.

Kevin:  So there's a huge ripple effect of this. I think we're very early on in these conversations. Especially if you are not a traditional CPG company.

Bob:  Yeah. That's what I was going to say. The future is already here, it's just badly distributed. [inaudible 17:02] .

[laughter]

Kevin:  That's a great way to say it, yes.

Bob:  Yeah.

Kevin:  Years ago, 2004‑ish, I was a senior product manager for AOL. We did have it figured out, business and IT together, had a PL. Everything we did on a weekly basis was outcome driven, and it made perfect sense at the time. A lot of companies were not there.

Bob:  Were you out in the Virginia area?

Kevin:  This was AOL Columbus. Remember they bought CompuServe a million years ago. Netscape ran out of Columbus. We spent two days a week in Dallas, but primarily it was Columbus.

Bob:  OK, because we did a lot of the early work with Agile with AOL, but it was all near our scenic Herndon office.

Kevin:  We were doing Bluegreen employments every Wednesday morning and we didn't even know that that was a thing back then. It was just how we deployed code, yeah.

Bob:  That's great. Is there anything you're going to take back that you think will be impactful?

Kevin:  I am. We're in the midst of modernizing our tools that support program and project management and Agile life cycle management. We've made significant progress in how we organized IT, how we execute Scrum and XP across IT. We have not modernized any of the tools that people use to actually do that. We're going to fix that in the next couple weeks.

Good conversations with a lot of companies that are either a bit farther along than we are or recently made a change. It's been great learnings for us and that team that's here to do that.

Bob:  Great. Thank you so much for the chat. It's always been a pleasure working with you.

Kevin:  Bob, it's always a pleasure.

Bob:  [laughs] Good.

Kevin:  Thank you.

Bob:  Bye.

Photographer:  Can we do a picture?

Bob:  Sure.

Kevin:  Because no one will believe that I was on a podcast.

Bob:  Well, they will.

Kevin:  Was that OK?

Bob:  Yeah. It was perfect.

Kevin:  You do this all the time. I'm new at it, so...

Bob:  Well, yeah. They're all this sort of conversational... [laughs]

Kevin:  Did it take?

Bob:  Yeah.

Photographer:  Yep.

Kevin:  Cool. All right. Thank you very much.

Bob:  Great. If you're going to tweet it out, I'm @agiletoolkit.

Kevin:  Cool.

[pause]

Bob:  The Agile Toolkit Podcast is brought to you by LitheSpeed. Thanks for tuning in. I hope you enjoyed today's show.

If you'd like to give feedback or be on the show, you can ping me on Twitter. I am @agiletoolkit. You can also reach me at bob.payne@lithespeed.com. For more free resources, transcripts of the show, and information about our services, head over to lithespeed.com.

Thanks for listening.

[music]