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]