Single Point of Contact:<br />Donna Knapp

HDI’s SPOCcast is your single point of contact podcast for service management and support insights. For Episode 15, I interviewed Donna Knapp via Skype about DevOps, ITSM, ITIL, organizational change, and more.

RA: Let’s talk about DevOps a little bit. It is now certainly firmly entrenched in the industry, and one thing that I’m interested in is what’s going on in terms of the organizations that are using DevOps. Have you seen changes in the types of companies that are seeking training for DevOps?

DK: Absolutely. And, you know, you’re right: DevOps is here….DevOps, I think the term itself is eleven years old now, so it’s been around. And I think the big difference is, it’s finding its way onto the enterprise…and that’s been going on for a while now. But, you know, its roots were big technology companies—the Facebooks, the Amazons, the Googles of the world—and now it’s finding itself in large enterprises. And interestingly, it’s finding its way into, first, pretty heavily regulated industries—so, finance, healthcare, and certainly retail. And there’s a few reasons behind that: One is that those are just competitive market spaces and so there’s this real need today—to stay alive in those industries—to be innovative and be smart about how you’re leveraging technology.

I recently got a letter from my healthcare provider that they’re going to start providing video conference appointments from those people who opt to do that, which is awesome, right? How excited are we about those kinds of things? Companies aren’t doing that kind of innovation and introducing those kinds of new ways of working and constantly evolving those new ways of working without introducing some of the practices that are part of DevOps. It’s slowly finding itself into the government, you know, as Agile has found its way into different government agencies, DevOps is very much on its heels. So, wherever there’s great demand to innovate and to enable higher levels of velocity, you’re going to find DevOps.

RA: Do you see an increase in the number or types of roles that are seeking to learn more about DevOps? Is it broadening across the industries that are putting their feet in the water? How far across the organization is DevOps being used, do you think?

DK: What’s kind of interesting about DevOps—let’s talk about DevOps in the enterprise—a lot of DevOps initiatives in the enterprise started in Dev (software development). So they  would literally stand up like a greenfield environment, they would have a pilot, and they would kind of run a little experiment to see if they could introduce…the technologies that are associated with DevOps and have, you know, an automated toolchain that enabled them to speed up. And in the early days it was very, very common to see organizations introduce DevOps without ever talking to Ops, which is sad.

Now we are absolutely seeing where the Ops folks are getting engaged and some of the practices that are the next evolution of DevOps, like Site Reliability Engineering (SRE)…their roots are in Ops. So, we’re seeing the Ops folks getting engaged, we’re seeing the IT service management folks getting engaged, which I know is a bigger part of our conversation…but also certainly security—DevSecOps is probably a term we’re hearing more starting last year and into this year, than even DevOps in and of itself. So, the security folks are getting engaged and quite frankly the QA, the testing folks have always been engaged, because continuous testing is one of the components of DevOps. So, the good news is, across the IT value chain, we’re seeing folks who are getting engaged in understanding that they have a role to play in DevOps.

Where we need to do more work is in getting the business folks engaged. And there’s actually some really interesting work that’s coming out these days that is talking about the fact that there’s a lot of organizations who have made significant improvements with DevOps so they’re able to release much more quickly, their releases are much more reliable, they’re achieving all of those things that are the promise of DevOps, but they’re still not necessarily moving the dial from the business perspective. So, they’re not yet able to connect the dots…“as a result we’re seeing increased revenue” or “as a result we’re able to attract new customers.” So that’s kind of the next conversation in the DevOps community in terms of how do we engage the business folks.

RA: I think of organizations like Lockheed Martin years ago that had a Skunk Works®—small teams, focused on highly innovative projects—which sounds a little bit like DevOps. Is there a way to get business to see that as part of the paradigm, or are they already seeing it, do you think?

DK: I think they’re seeing it to some extent, but I think they haven’t necessarily—and we can never say “all organizations” or “every organization”—I do think there are organizations out there who, the leadership in the company is saying all the right things. “We need to be more agile. We need to be more innovative.” But they’re saying those words, and in some cases I think those words are being taken in the context of how they’re defined in the dictionary. “We need to be more agile.” In other words, we need to be able to change more quickly, we need to be more flexible. Let’s call that agile with a little “a.”

We also have Agile with a capital “A.” There’s a method there, right? There’s an approach there. So, for example, for DevOps to truly be successful, then their business counterparts need to understand that these are going to be Agile projects, that we have to move away from the traditional, “Define all of your requirements, sign off on the design, and then we’re going to start development.” We have to have just enough of a requirement in order get started working on something, and then we’re going to show you what we’ve done, and then you need to come back and give us some really fast feedback. So, some of those fundamental principles of Agile that underpin DevOps, the business has to learn and embrace.

I had someone tell me one time that their business was very excited because DevOps was being introduced because it meant that they weren’t going to have to come to the project reviews anymore. Well, how they got that idea, I’m not sure, but that’s not anywhere close to the case. It’s even more important that they come to the product reviews so that they can be part of that fast feedback cycle. So, I think it is a matter of understanding that there’s really good, solid principles behind things like Lean and Agile and Service Management, and let’s add DevOps into the conversation about that, because we could talk about things like continuous delivery, and understanding that it is a method, it’s not just a word, and we’ve got to change our ways of working accordingly.

RA: You certainly know what you’re talking about in terms of IT service management—or maybe we just call it just plain service management these days—and you’re also firmly planted in the DevOps world. There’s been a border between those things historically speaking, and you mentioned a little bit earlier that some of the service management folks are getting more involved now. But also, there seems to be—at least in terms of the public face—the information that’s coming out of at least some corners of the DevOps world—there’s a widening chasm, and some people are completely discounting IT service management, ready to toss it in the garbage can. Why is that happening, do you think, and will that chasm continue to widen until one side “wins,” whatever that means?

DK: I want to come in on the “until somebody wins” part first. Nobody’s going to win if one side wins…. We will all win when we understand that Agile, and Lean, and service management, and DevOps all work together. They all help each other, right? That’s when we’ll win, when we understand all of that.

We will all win when we understand that Agile, Lean, service management, and DevOps all work together.

RA: Thank you!

DK: There’s no “or” in that conversation, ever. To speak to the chasm: So, I want to talk a little bit about the difference between DevOps and IT service management, and let’s just lay ITIL^® on the table, because it’s the elephant in this room. But certainly there are other service management frameworks. We can bring COBIT into the conversation. If you look at how ITIL has evolved over the years, ITIL has, about every 10 years, introduced a new version of their body of knowledge. And we’re now in 2019, ITIL 4 is being introduced now. ITIL version 3, so to speak, was actually introduced in 2008. In 2011, they did a little bit of a rework on the books, but they didn’t necessarily…there was no fundamental change in the contents. It was really more a re-jigging of the books. The last release of ITIL that everybody’s working off of today came out back in 2008. DevOps was swirling about, but really hadn’t even evolved at that point in time. So, the current body of knowledge we’re all working off of from an IT service management context, you have to work really, really hard to find any aspects of that that speak to Agile development methodology, these DevOps-type practices. You can find these little glimmers where you can say, “You know, standard changes can relate to DevOps.” But really, you have to work pretty darn hard.

DevOps, on the other hand, still does not have a definitive body of knowledge. We refer to a collective body of knowledge when we talk about DevOps. So, the way DevOps has evolved is through a community of people contributing articles online. There are some publications. There’s a couple of really good publications that have come out in the last couple of years, but just in the last couple of years. And certainly things like DevOps Days and the DevOps Enterprise Summit. So, this community has learned from each other and the practices have kind of evolved, and so this community is always learning new ways of doing things.

So, if you look at the difference between ITIL Best Practice—and best practice by definition lags, right? How long does it take something to rise up to being recognized as best practice? Best practice is always going to lag behind what’s going on in the industry. And then if you look at how DevOps has been introduced, it’s been introduced through this kind of ongoing, evolving, and emerging practices. So, where they came from and how they continue to evolve is different.

Now, having said that, that doesn’t mean we can’t work together...The ITSM community has to be willing to learn about DevOps, and the DevOps community has to be willing to learn about and understand IT service management, and we just have to kind of talk to each other and figure out how to work together.

I kind of want to say one last thing about this. If you look at the highest performing organizations in the context of DevOps, they’re not doing that without IT service management. They are managing changes, they are handling incidents, they are handling requests for change. They’re just doing it differently, and they’re not calling it the same things. They’re taking different approaches to how they introduce these IT service management practices. So, they’re not doing it without IT service management. Again, they’re just not calling [it] that. But they’re also not doing it with the kind of overly rigorous, fairly heavyweight processes that some organizations have introduced as a result of flowing ITIL as if it were cast in concrete…. It’s guidance. It’s never been prescriptive. It’s never been intended to be prescriptive; it is in fact guidance, it just doesn’t get implemented that way in some organizations.

RA: On that note, which aspects of ITSM as practiced, distinct from as it is in the books, or as imagined or as conceived, are the most troublesome for DevOps practitioners, do you think? And can those be improved or mitigated, or should they just be done away with—you know, get out of the way?

DK: So, the first obvious answer is change management, what we’re calling in ITIL 4, change control…. We have always overdone it with change management. In a lot of organizations, there’s a lot of very “one size fits all” approach to how changes get managed, and ITIL doesn’t even say you should do that. So if we just followed ITIL’s guidance, in terms of understanding that there’s different types of changes, and that we can have models for different types of changes that have different procedures and different levels of authority—even if we just practiced ITIL the way it is in fact written, we’d be better off with change management. But with DevOps in the mix, we now have to understand all of the really awesome things that the DevOps community is in fact doing that satisfy the requirements of change management.

So, if we can all agree that we need to have a record of the change, and that we need to have some testing and evidence that testing has occurred, that satisfies the controls of change management, whether they be things that have to be addressed for regulatory purposes, or simply they reflect the internal policies of our company. We can introduce policy as code today, right? So, in making changes through a DevOps pipeline, all of that can be done automatically. And so, what that looks like is a developer…introduces a piece of code, sends it down the DevOps pipeline, a bunch of testing gets done, a record gets produced, and the change manager can look at it and say, “Awesome. You satisfied the objectives of the change management process.” So I think in general if we can focus on the what and the why of change management and not the how we do it—as in changes have to go in front of the CAB (Change Advisory Board) and be approved—we’ll be a lot better off.

Incident management is another one, where the DevOps community has really embraced safety culture, and in safety culture, there’s this old…analogy that the companies that report the most incidents are the safest, which is kind of counter-intuitive. But what it says is those companies are willing to make those incidents visible and are willing to work on and try to prevent those incidents from happening…I think with incident management you see a lot more emphasis on—again—understanding that not all incidents are created equal…In IT service management very often there’s this perspective of the traditional Tier 1, Tier 2, Tier 3 escalation path, and that just slows stuff down. So in the DevOps community, you’re seeing a lot more swarming, and you’re seeing a lot more kind of dynamic responses to incidents—the Incident Commander concept, for example, that you see in safety culture.

So, again, it’s funny, right, because they’re doing, they’re making changes, and they’re actually recording those changes. They’re handling incidents. They’re just doing it in a very different way….

RA: If you, Donna, were to construct a framework for where we are in terms of tools, technology, governance, and business needs, and all the things that we’ve talked about, what would you put into that framework and what would you leave out of that framework?

DK: I think there are great frameworks already out there, and what we need to understand is how to better leverage those frameworks. If I could introduce a new framework, it would be a framework that would integrate with all of the existing frameworks, and its focus would be on culture, and its focus would be on things like organizational change management, and management in general….

I do believe sometimes when DevOps isn’t successful in an organization or where IT service management isn’t successful in an organization…It does make me sad that I think there are a lot of folks who go to work every day dreading going to work, and who, in the course of doing their work are being asked to do things that they think is stupid, or that they know is just counterproductive, but it’s the policy, or it’s the process that’s been put in place. And the management team is measuring them based on whether or not they do these things.

So, I do think middle management and supervisors within an organization really hold the key in terms of whether or not any of these initiatives are going to be successful within an organization. They are the ones who are either going to maintain the status quo and keep the company bound to these old ways of working, or they themselves are going to evolve, and they’re going to learn more about coaching and more about organizational change management—and not just talking about those things, but actually taking action day in and day out to move their organization to a higher trust culture, to move their organization to a place where people really enjoy coming to work every day and who take pride in what they’re doing, who are respected for [being] the professional adults they are, and allowed to work autonomously and creatively.

So my framework would be one where we really figure out this culture thing, because we know culture’s important, we know organization[al] change is important, we talk about it a lot, there’s bodies of knowledge out there about it, but we still don’t really do it well. And I would like to figure out how we can do it better.

About Donna Knapp
Donna Knapp has more than 30 years of experience in the IT industry and is currently ITSM Academy's curriculum development manager. Donna's years of practical experience and love of learning show in her engaging and informative speaking style and many certifications, including ITIL Expert, Certified Process Design Engineer, DevOps Foundation, Certified Scrum Master, Certified Agile Service Manager, Certified Agile Process Owner, and VeriSM Foundation. Donna is the author of The ITSM Process Design Guide: Developing, Reengineering, and Improving IT Service Management, as well as two college textbooks, A Guide to Service Desk Concepts, Fourth Edition and A Guide to Customer Service Skills for Service Desk Professionals, Fourth Edition. Donna is also on the DevOps Institute's Board of Regents.  She is a frequent speaker at HDI events.

Roy Atkinson is one of the top influencers in the service and support industry. His blogs, presentations, research reports, white papers, keynotes, and webinars have gained him an international reputation. In his role as senior writer/analyst, he acts as HDI's in-house subject matter expert, bringing his years of experience to the community. He holds a master’s certificate in advanced management strategy from Tulane University’s Freeman School of Business, and he is a certified HDI Support Center Manager. Follow him on Twitter @RoyAtkinson.