Jayne Groll

Part of what I'm going to try to do today is look at some of the very common objections that come from the ITSM side of the house and show you ways inside of DevOps for us to overcome that. And I'm also going to hopefully acknowledge and dispel some myths around the relationship between IT service management and DevOps.

So as Chantelle said, I am a board member and one of the co-founders of the DevOps Institute. I'm also president of ITSM Academy. I've been a trainer in the ITIL space for almost 13 years. I have a lot of certifications. I'm an ITIL Expert. I'm a Scrum Master. I've been very involved in the DevOps community for a while.

So hopefully, part of what I bring to you today is a little bit where there's a crossroads, where we start to look at DevOps less as it's a framework in its own right, but more as a super framework, where it connects all the dots between other things that we've already invested in in our organization.

I'm also the author of the Agile Service Management Guide. So part of my message is how to bring service management into a much more modern approach, not necessarily by reinventing the processes, but by re-engineering them. So we'll talk a little bit more about that.

Just to tell you a little bit about the DevOps Institute, we launched about 18 months ago. We are a global learning community. So again, the goal is to be able to bring DevOps education and some DevOps certification through our channel of registered education partners. And again, if you're interested in learning more about that, please come and see me afterwards.

So let's start with: why aren't DevOps and IT service management friends? And if you look at the graphic here, you can pretty clearly see it's a little bit of my way, your way.

So as we were growing IT up, and I've been in IT probably a little longer than I really want to admit to, we grew up in a very siloed way. So we had development investing in their practices, and we had operations investing in their practices, and somewhere along the way, we recognized there was a need for process re-engineering. As IT started to grow from 25 people that sat in the same room, sat on the same floor, knew each other, to 1,000-person multinational organizations, the need for a little bit more structure and control, and then you introduce things like HIPAA and SOX and governance and compliance, and the need to structure and formalize process became more important for organizations so that they could demonstrate some of the compliance.

One of the great myths is that DevOps is incompatible with IT service management. And I use IT service management because while ITIL is the most prominent of the frameworks, there are other IT service management frameworks. You might have known what Microsoft Operations Framework is, COBIT, ISO 20000, the international standard. So there are multiple frameworks, but at the end of the day, they're really all saying the same thing: that there is a cycle of process that exists among the service lifecycle from conception into production and beyond.

And as we started to grow this, and then we started to invest in DevOps or start to become interested in DevOps, there became a kind of a sidebar of how do we build continuous delivery, which is really, at some aspects, release management. How do we intersect with change management? Or what about support, and how do we move forward in support?

So the recently released DevOps Handbook actually really called out the fact that ITIL, among all the other IT service management frameworks, really has influenced, over the past, let's say 10 to 20 years, generations of ops practitioners.

Now, there's another myth I want to start off by addressing because I think it's very important. So how many of you think that ITIL was built for Waterfall?

Nobody? Really? A few.

The answer is it was. Really. It was. It was built for Waterfall because at the time that it was conceived back in the 1980s, Waterfall was the software development approach. And as it graduated through various versions, Waterfall was still the primary development approach.

And like your developers, where you needed to now transform your developers from Waterfall to Agile, IT service management is now at the crossroads where it also has to graduate from a more linear approach to a more dynamic approach. So we do need for these processes to become more agile, and you can help make that happen.

There's nothing wrong with the processes, and we need to remember also that these processes are just processes. They're not departments. You might have a change advisory board that's human, but they're just processes. And the mantra of ITIL and other service management frameworks has always been adopt and adapt.

So given the modern challenges of the IT organization, we have to adapt. We have to adapt to the changing business requirements. We have to adapt to the faster flow of work. We have to adapt.

And so part of overcoming some of the objections from IT service management and really becoming best friends is really leveraging the power and the strength that sits behind those processes, and then identifying what is, today, just enough process. We use the term minimum viable process. So for your organization, based on what you're trying to release, what is minimum viable process, and how do we address that?

So as I said, I really wanted to take that myth head-on because the truth is, when it was conceived, like when a lot of your products were conceived, it was Waterfall. But today, we're migrating to Agile, and service management is migrating in the same way.

So I really want to look at some of the objections that you might be facing or you might be putting forth to some of your DevOps and development colleagues.

Let's start with change management. So of all the processes within IT service management, this is where the rubber meets the road. This is the process where organizations have likely invested a lot of time and a lot of energy formalizing some type of change management process.

And you may be subject to putting a request for change in seven days, 14 days, five days, three days, one day before you want to release something into production. And in a DevOps type of environment, that's not necessarily sustainable. Or it's unnecessarily sustainable because you may be releasing five minutes after you develop the product, and you may be pushing it through an automated deployment pipeline.

So we really want to look at what are those objections and how do you overcome them. Well, first of all, change management is not a technical process. Does everybody get that? It's not a technical process. It's a risk management process.

The whole goal of change management is to manage risk. So the question of the risk is: do we make this change or don't we make this change, and what's the risk if we don't do either one? So if we make the change, there may be some type of risk, and if we don't make the change, there may be some type of risk.

So the whole reason you have a change advisory board and you have change models is to be able to manage risk. The truth is, it's not a one-size-fits-all process. It was intended, and if you look into the ITIL books, it was intended to be built with models. So depending on the level of the risk would depend on the level of the rigor.

So if you look at the objections that come out of change management: there are way too many risky behaviors going on here. Because we want to push a button and send things into production, and it isn't going through our usual level of rigor.

Well, the question is: what's the change? How risky is that change? We'll talk about that in a second.

Your objection: you have to submit a request for change X amount of time in advance. Well, you're going to see on the next slide, there are changes that are legitimized inside of service management that you don't have to put a request for change in at all. And that was approved. That was approved. You don't have to put it in.

Now, there's a difference between a request for change and a change record. So we still do need to have a record of the change, but we don't necessarily have to ask for it.

And so that's a big way to overcome the objection: to work with your change management team and identify when do we have to put the request in, again, based on levels of risk, and when do we just need to record a change record? And maybe the definition of today's change record is different than the definition of yesterday's change record.

Maybe it's commented code is our new change record, and we teach the change teams how to read that so that they understand and they can answer the question of what changed.

And then the third objection: we don't know what changed. We have no idea. We have no access to logs. We have no access to some type of change schedule. You push a button and five minutes later it's in production, and now suddenly incident management and problem management are having to support that.

So that's where, again, you can come together to identify what knowledge does the production side of the house need in order to be able to manage that change.

So how do you overcome that? Well, first of all, ITIL in particular calls out something called change models. Who's heard of change models? Who has change models?

Okay, awesome.

So when you build a change model, they're risk models. And depending on the rigor or the level of risk, you make a choice in terms of what steps need to be predefined in order to mitigate that risk.

We'll look at standard changes in a minute. You can leverage your automation. We build APIs between a deployment pipeline. Why not build an API into your ITSM tools so that when a change is made, it creates a change record?

We've become really good at building APIs. So there's no reason that a developer or somebody else has to actually type in what was done and when it was done and all of that. There's a lot of ways to auto-populate that information as we're going along.

And then the last suggestion is my personal favorite. Put an ops person on your Scrum team. And it's not a passive role. It's not that they're there to listen. There's actually some really active tasks that they can perform that prepares your operational processes as well as your operational teams to be ready for what else is coming down the pipeline.

So they can actually play a very important role. They can start to understand the language. They can start to cross-pollinate the practices. So if you have a Scrum team, put an ops person on that Scrum team. First round, first sprint: stranger in a strange land. As they start to become more familiar with, again, the vernacular, the practices, they start to become more agile. Then they can go back to the operational teams and to teams like the service desk and start to prepare them. They can serve as your ambassador going forward.

So I think of all the things that we look at inside ITIL and ITSM, this is the most powerful. Everybody wants more standard change.

A standard change is not a break-fix. There's a little bit of a misconception about what a standard change is. It's not a break-fix. It's a low-risk change.

And if you're putting a release through the deployment pipeline, it's actually going through more rigor than it would if it went through manually because you have consistent testing strategies. You have automation. You've built a certain level of compliance in that pipeline because there's consistency between release, release, release, and release.

So once you've started to master the smaller, more frequent releases, and once everybody's comfortable that we do recognize risk, that we're not in denial about risk, then a lot of your changes can be defined as standard.

And if you look at this definition of standard, it is pre-authorized. It is low risk. It's pretty common. Push that button, send it off into staging or into production. It does follow a procedure, even if the procedure is automated. It is not required to submit a request for change. All right? That's direct from ITIL.

So if you don't have to put in the request for change, you can go faster. Still need to create a change record of some kind, but you can go a lot faster, and you're still conforming to the best practice guidance of change management. And it can be logged in a different mechanism.

So it doesn't necessarily have to be logged in ServiceNow or Remedy or whatever tool you're using. Again, my recommendation would be to see some way to automate that. But as long as the support teams have access to that information, you log in wherever you want. It becomes a part of the configuration management system.

So the question is: could DevOps and ITSM become best friends by agreeing what the definition of a standard change is? And again, it's not break-fix. It's not just I have to ghost your laptop so that I can give you a new one.

At some point, we advocated for 80% of changes to be standard. Now, maybe that's really hard to reach, but what a goal. If 80% of your releases are standard, then the other 20% are the big, ugly, high-risk, project-based type of changes.

So we look at release and configuration management in relationship to change management. This is actually delightful to me because I've been teaching ITIL a long time, and the most misunderstood process in the ITIL service lifecycle is release management.

So if anybody's ever taken the old ITIL Service Manager exam, if you had to write an essay about release management, you more than likely failed. Because individuals didn't understand that release management was not a stepchild of change management.

Release management's a fairly technical process. Change management really isn't. But DevOps gives release management not only credibility, but it gives it the tools that are needed to make releases lower risk. It brings release management to the forefront, and it allows a deployment pipeline that makes releases less risky because they do go through a certain level of automated testing, and if the testing fails, it goes back. We can read the test logs. We understand what that all means.

So if you look at the objections: we're sacrificing quality for speed. Well, overcome that. Your deployment pipeline, again, has rules built into it that determine when a release can go into either staging or into production, and if it fails those rules, you can take it back. There are absolutely compliance hooks that are built into the deployment pipeline.

The tools and the definitions are not aligned. I think this is a very critical area. If you're doing configuration management on the dev side, raise your hand. Configuration management on the dev side. Configuration management on the ITSM side.

Are the two hooked together?

Yes. Yes. Most of the time, no.

So we're building a CMS or a CMDB and an ITSM tool, and then we're building configuration management through a DevOps tool. So dev has its configuration management, and ITSM has its configuration management, and we really haven't built a bridge between the two. And again, one of the things that DevOps is really encouraging is: let's build those bridges. Let's build those interfaces so that it isn't which one is right, and the frustration on either side isn't we're releasing into a mythical environment because that's what the configuration management system is telling us we have, and the developers are building against an environment or building a configuration that may have more risk than necessary.

So again, big objection: our data is not passing. So maybe we don't need two tools. Maybe we can build an API between the tools. Maybe we can auto-populate those tools.

And by the way, the tool providers would like that. They would like that. Your DevOps configuration management tools, they would really like that to go through the deployment pipeline and end up in ops. Your ITSM tools, they would really like to be connected into the rest of the pipeline.

So we certainly want to get the ITSM release managers and configuration managers engaged in the architecture. So as you're architecting your deployment pipeline, as you're really starting to look at your configuration management tools, why not engage those folks?

In fact, in most organizations, the release manager may not actually have been designated. So the ITSM release manager may actually be your DevOps release manager. And that would be great. That would be great because, again, there's that link between the two. So we certainly want to make sure that we can do that.

We really want to demonstrate that testing is more robust than ever, a little bit of proof of concept. But we also want to capitalize on some of the capabilities that ITIL and ITSM brings. A release policy. Definitions of different types of releases: major releases, minor releases, and emergency releases. And then, as I said, we really want to start looking at APIs that start to build the bridges between the tools.

And so incident and problem management: one of the challenges that I see when we start to talk about continuous delivery and continuous deployment is it ends at deployment. So what happens after that? What happens to the release after deployment? Because then we go back to development.

So should there be an operational pipeline that it gets handed off to? And maybe that's why there's some frustration between your ops teams. And when I say ops teams, we're really looking production support, whatever level of production support you have.

So service desk, last to know. We don't have incident records. Can't answer what changed. When we have an incident, we can't find the developers. Knowledge. So there's knowledge on one side, knowledge on the other side, and that's certainly not being shared.

And there's too much emphasis on MTTR. MTTR is a great metric. It's not the only metric. So let's look at other metrics like change success rates. MTTR is how you fix something that breaks. Let's look at things that didn't break in the first place and really celebrate that together.

I talked a little bit about using automation to be able to create knowledge, change, incident, and problem records. So certainly, there's an opportunity to build that bridge.

I think ChatOps. How many of you are familiar with ChatOps?

Wouldn't ChatOps be amazing if you could engage your production support teams on Slack channels or whatever other ChatOps tools you're using? So if there is an issue, there's almost instant access, and you can bring the environment in, and you can have healthy discussions, and you can look at dashboards together. And it really gives almost a virtual collaboration between those that are going to support your release post-production, the happily ever after, and those that have gone into development after that.

And then the final piece is you have to agree on service level and resolution metrics. You have to work together and say, "Let's have shared accountabilities. And how do we make those metrics meaningful?" Because inside the metrics are going to be opportunities for improvement.

Could be the beginning of a really beautiful friendship, right?

I like this term: control without being controlling. And that's a little bit of a message to the ITSM community. Control, but don't be controlling. And how you figure out where that line is, where that just enough process is, minimum viable process is, you have to talk to each other. You have to start to cross-pollinate vocabularies, start to align your processes, even agree on the same process. That would be great. Look at your metrics.

But if you look at the top, you have to trust each other. Everyone is competent. There's not a person in this room, and there's not a person in an IT department out there that's not competent. Because if they are, they shouldn't be working with you.

There are competencies and strengths that maybe you don't have that they have, and they don't have that you have. So there really is a great opportunity for engagement, and there certainly is a great opportunity for sharing tools. We built them up in silos. We built them up separately.

And I will tell you one last thing, and I think this is very important. One of the biggest flaws in a framework like ITIL is when it came to software development.

So if you look in the service design book, anybody familiar with that? When you look in the service design book, it basically says we're going to design warranty processes like availability, and capacity, and continuity, and security. And then it says, "And go off and find the SDLC approach of your choice."

So basically, we said to the developers, "Here's the service lifecycle. You're here. Go find your own approach." And they did. They found Agile. They did. So they went off to their own island, and they found their own, and now we have to bring that together. And it wasn't intentional, it wasn't malicious, but it was certainly a key part of this, and now we have to be able to bring everybody back into the cycle.

PDCA. Everybody's familiar with Plan-Do-Check-Act? Somebody said in the keynotes yesterday, the faster you go through PDCA, the more you're learning. Well, everybody wants to go through PDCA faster because it's all about continual improvement. At the end of the day, that's the most important continuous of all.

So thank you. It was really just a fast taste. I hope you've gotten a couple of ideas to take away. Please make IT service management your best friend. There's a lot of value there. DevOps is really migrating into the enterprise, and I think it's a great opportunity.

Do we have time for questions?

Yeah, we do. We got five more minutes. Anybody have questions? Here we go.

Q&A

Q: So Jayne, one of the things that we have traditionally seen is that, who breaks the ice? Because you see the service management people, they're very focused on rigorous processes and stuff like that. So getting them away from the jinx of driving through this process towards what Agile or collaborative learning, where do you start with this kind of equation? Because it's great, but people are not willing to listen. So how do you break the jinx? Just a thought.

A: And Suresh, I think that's a great question. I personally think it starts with change management because I don't know about you, but the frustrations that we identify on both sides, and I hate it's Election Day, but on both sides of the aisle. Hopefully, this vote would go a lot easier. But on both sides of the aisle is change management.

So if you could start with the agreement of what is a standard change, I think that takes us light-years ahead of where we might have been. And then the rest starts to filter out because change management, risk management is kind of the center of the universe.

Q: How do you handle the fact that a lot of, say, your ITSM people think that DevOps is going to take their job?

A: That's a great question, and I'm going to answer it really easily because there's been floating around this concept of NoOps. You've all heard the term NoOps. And so if I'm an ITSM person or I'm an ops person, I didn't hear NoOps. What did I hear? No job.

So we're actually trying to float a new term. Call it NewOps. It's NewOps because we want, and I've been working on one of our courses, and Jez Humble, who you probably have met throughout the conference, says, "Let automation do the repetitive tasks and let people solve problems."

So we need to use those people to solve problems, to architect the ops side of the deployment pipeline, to read the test logs. NewOps, not NoOps. So please tweet that, float that, please, because we're really trying to get that concept out there that we really want NewOps.

Okay. Any other questions?

Okay. Well, thank you all so much. Thank you.