Jayne Groll

Welcome, everybody. I'm Jayne Groll. I'm CEO of the DevOps Institute. I have a long history in the ITSM and ITIL space, so we're going to talk a little bit about service management and DevOps today.

I was an IT director for a very long time prior to founding ITSM Academy in the early days of ITIL. I've since moved on from that and co-founded DevOps Institute in 2015.

I'm also the author of The Agile Service Management Guide. So if you're interested in learning a little bit more about agile service management, I'll give you a link at the end for you to go to DevOps Institute, and you can download the e-book for free.

A little bit about DevOps Institute. So we stood up in 2015. I was very blessed in the early days of DevOps to be invited to see it in its kind of startup phase, right, where it had really not crossed over into the enterprise yet. Gene had an opportunity to go to DevOps Days. I had the ability to do that. And so I've really been able to watch the growth of DevOps from its earliest days crossing over into the enterprise space, which I'm sure affects a lot of you.

We are an open member community. We also have the coolest socks on the planet, so if you come to our booth. Anybody gotten the DevOps socks yet? Oh, come on, right? Do any of my team want to show us what those awesome socks look like? Mark. Mark will show you. Yeah, Mark will show you, right?

So they are the coolest socks on the planet, so please stop by our booth upstairs and you're welcome to grab a pair. More importantly, we are an open member-based community. Membership's free. We're never going to ask you for money. So I would invite you to come and join us.

We have a framework called SKIL, S-K-I-L: skills, knowledge, ideas, and learning. Come up to the booth and we'll tell you a little bit more about it.

But let's talk about IT really as a system. So you're hearing a lot about systems thinking, right? Everybody's saying you have to be a better systems thinker.

Well, if you look at IT as kind of a system of systems, and you look at kind of how we've grown up, and by the way, we're a pretty young industry, right? So I'm married to an accountant, right? They were pushing around rocks in the very early days of humanity. IT is what? Maybe 50 years old? Maybe, right?

So we've grown up in kind of an interesting way where we created this system of systems. So anybody a developer? Okay, a few, right? So in development, you've been really focusing maybe on moving from waterfall to agile over the last several years, right?

And so the Agile Manifesto came out. Everybody said we have to really focus on some different things. Scrum became a pretty prominent framework, and that happened kind of in isolation from some of the other things that happened downstream.

And so once the product or the code comes out of the Scrum team, it goes downstream to today, maybe a CI/CD pipeline. In the past, it might have gone into your release management process, right?

So how many of you invested in ITIL? I'm guessing you're in the room for that reason. So over the last several years, we've invested a lot of money in IT service management, in large part in a very command-and-control environment. How many of you love your CAB? Oh, I got a couple. Awesome, right?

And part of what you're being asked to do today is to take that investment in ITIL and move it forward into DevOps, and there's a lot of confusion. In the early days of DevOps, ITIL was dead, right? It was like, "ITIL's dead, long live ITIL." You're no longer relevant in an agile and DevOps environment, and that's no longer true as well.

So the code or the product comes downstream. It goes through service design and service transition in ITIL v3. In DevOps, it goes through CI/CD, hopefully through a lot of automation, and then it deploys, right? The button either gets pressed or it presses itself, and it goes into operations. And we see a lot of IT service management in operations: incident management, problem management, service level management, change management.

Who loves change management? So there's a few more people than the CAB, right? We're going to talk a little bit about change management today.

And so we have this system of systems. The problem is, while the rest of you were investing in ITIL and the developers were investing in agile, you didn't do it together, right? And by the way, it's our fault in ITIL because in ITIL, in the service design book, we told you all about availability and capacity and security, and then we said to the developers, "Go off and find your own SDLC approach." And you did, right? You found Scrum.

So we sent you off the island and said, "Go find your own homeland." And you did. And the rest of us moved forward with ITIL.

Well, where we are today, I think, is really important because you're hearing a lot about moving from project to product, right? Is everybody hearing about that? Mik Kersten wrote a fantastic book. If you've not read it, please get it at the IT Rev booth, right? And it's really changing your mentality from project management to product management.

But I'm going to tell you, we need to go from project to product to service, right? Because a product only delivers value if it's delivering service to somebody that's actually going to use it, right?

You're all holding a mobile phone in your hand, right? The fact that it's a product means nothing to you. The fact that you can do something with it is important.

So the reality is value's only created when you use a service, right? So service management is still relevant. So if you take nothing away from today's talk, service management is still relevant, right? You still have to manage services. Hasn't changed in DevOps. How you manage it may be a little bit different. We're going to talk about some different ways, right? It's always going to need to be managed. The question is how, right?

So today, we're going to look at a couple of different approaches, both of which are emerging very rapidly in this space.

How many of you are hearing about ITIL 4? Right? Anybody taken ITIL 4 Foundation yet? Oh, a couple of you. Okay. Good, brave souls, right?

So talk a little bit about ITIL 4. There's some good things in there. There's some things I personally wish were either different or it's more to come, right? It hasn't necessarily completely been revealed because it's coming over a period of time.

How many of you are hearing about site reliability engineering, SRE? Any SREs in the room? Couple, right? A couple. So we're going to pull on you for your knowledge as well.

If you're not hearing too much about SRE or you're really not familiar with it, Google says it's their approach to service management. So everything else you hear about SRE, at its core, it is a service management approach, but it is all about operations. Whereas ITIL tried to really cover the entire lifecycle, SRE is really about service management from an operations perspective. I like to call it continuous operation.

So we're going to see how both of those play with the Three Ways.

So how many of you are familiar with the Three Ways? Some of you. Anybody not familiar with the Three Ways? Okay, I'm going to give you a little bit of an oversight of what the Three Ways are.

So you've heard of the book The Phoenix Project. Gene wrote The Phoenix Project with some others. It is, I don't know, three million copies later, really became the heartbeat of DevOps, mostly because it's a fable, right?

If you've not read it, anybody not read The Phoenix Project, you can say it here, it's okay, right? It is okay. If you haven't read it, I would encourage you not only to read it, but read it with your colleagues. Start a book club because it is a fable, right? It is a novel.

So you get to figure out whether you're Brent, and people who have read it know what I mean, or whether you're Patty, right? So, again, there are characters in there that you very much can identify with. And within that fable is something called the Three Ways.

So basically, the Three Ways of DevOps have a kind of a different approach. One is right to left, one is left to right, and then we have a continuous practice that's associated with it.

So the First Way is we have to improve flow, right? So we have to improve flow from left to right, which means some of the things that happen later in the cycle have to shift left so they happen earlier in the cycle so that we can go faster, right?

So testing is a great example of that. Used to be it comes out of the Scrum team, it goes downstream, it goes to QA. QA tests it, maybe they send it back, maybe they go forward again, right? All of that. But in a shift-left environment, testing starts with the first line of code, right? So we can start to do very pervasive, perhaps automated testing all the way through.

So that's the First Way. You have to go left to right and make that go faster. You have to increase flow. We'll talk a little bit about theory of constraints in just a minute.

In the Second Way, you have to shorten feedback. So anybody ever do waterfall development? Right. Okay. Some of you, right? So in waterfall, you kind of go down the waterfall, very linear, and start here, and then you go to the next step, and the next step, and the next step, and testing happened way down at the bottom, so usually just before production. There might have been some testing happening along the way, but really user acceptance, all of that kind of happened at the end.

The problem with the waterfall is it's pretty easy to slide down a waterfall. It's pretty slippery trying to slide back up. So we sent a lot of things into production that maybe had defects, right?

So in an agile environment where everything is very incremental and iterative, right, so little bits at a time, we can do testing a little bit faster. But we also have the ability to shorten our feedback so we can talk more, we can provide input and feedback, hopefully before it goes into production. So that's the Second Way.

The Third Way is the most interesting one. So the Third Way says you can't become a master if you don't practice, right? So we have to create environments that encourage practice, right, that you have the ability to learn on an ongoing basis. You get the ability to fail. Isn't that scary? Right. You get the ability to fail, but fail mindfully and fail fast so you can recover quickly. And you get the opportunity to continuously learn. And so it is a very iterative cycle.

And so your companies are now being encouraged to be able to give you the opportunity to practice. Have you heard of chaos engineering? Right? They send the chaos monkey into production. It breaks things randomly. You don't know when it's going to happen, but you get to practice recovering from it, right?

A woman I know works for a major British contractor, wants to put the chaos monkey in fighter jets, right? Do you want to be in a fighter jet, right, and the monkey just shuts things off? But it's the best way to recover.

Anyhow, so what I want to do for the next few minutes is really look at ITIL 4, SRE, both as service management practices. How do they relate to the Three Ways? How do you kind of optimize them for DevOps? At the end, we'll talk a little bit about change management because that's the crossroads, I think. I think the biggest struggle is how do we deal with managing changes in a very, very fast environment.

So some of you have mentioned ITIL 4. Now, for those of you who don't know what's going on with ITIL 4, they released the first book. So it's ITIL 4 Foundation. Each of the books is now mapped to a certification, so in some levels, they're textbooks, right, with more to come. I don't know exactly, if some of you know when more to come is coming. I would... But there is more to come. So it's going to be released kind of in a cycle over a period of time, probably at least a year. And so we're going to get more and more insight into what's in ITIL 4.

But in the Foundation book, they introduce something now called a service value system. So if you know anything about Lean, anybody know about value stream mapping? Yeah, right. So it's really kind of embracing this concept, first of all, of value, and second of all, it's embracing the concept of the value stream, all right? The stream of value from when an idea occurs to when it delivers value to a customer, and then bakes in some of the things that we've seen before that are a little bit more of the traditional cycle, right?

So some of the phases have changed names, but again, there is homage paid to DevOps and Agile in the ITIL 4 Foundation book. Not a lot of depth, right? Not a lot of depth. Not yet, right? And I say it's a little bimodal, truthfully. It's kind of saying, "Here's all the stuff that we've told you before. It's all good stuff. You could keep doing that, or you could do continuous delivery."

So again, kind of waiting for a little bit more depth of knowledge about that, hoping that the future publications give this to us.

They've replaced the concept of process with practice, which that is not just semantics, right? So we want to understand what do we practice. Remember that Third Way? What do we practice on a daily basis?

Still has a pretty healthy number of practices. That's okay, right? Still looks at incident, change, still going back into the design layers, going backwards and forwards from that.

The publications, as I said, are matched to certifications, so there's a lot more in each of the publications from what I understand talking to the publisher, but they are trying to map it, too.

How many of you are ITIL certified? How many of you are ITIL certified beyond Foundation? Okay. Healthy number of you. So same thing, ITIL Foundation is the basis, and then you can move forward from there.

Very strong focus on governance. And I will tell you the difference between the two is really SRE is less focused on governance, whereas ITIL is more focused on governance, and I think that it depends on your organization. Again, I want you to understand it's not an either/or. At the end, we're going to bring it all together, right?

ITIL really focuses on a regulatory approach. That's why the CAB. SRE focuses more on self-regulation, right? So it does have still a very strong relationship. And there is the promise of future alignment to DevOps and Agile going forward. So again, we start to see a little bit of the hooks into it: things like peer-to-peer review and change management, things like a continuous delivery reference, but still not a lot of depth. So I can't tell you a lot more, but I can tell you that the guiding principles of ITIL 4 very much do align to DevOps.

So anybody ever read the practitioner book in ITIL or take the certification? Unfortunately, it didn't gain the kind of uptake that everybody was expecting. But the guiding principles have now moved over from practitioner to ITIL 4. And if you look at these, these are great guiding principles, right?

Focus on value, right? Don't focus on technology, focus on value.

Progress iteratively with feedback. Sounds a little like the Second Way, right? We want to shorten our feedback loops.

Think and work holistically. Systems thinking, right? Something that in IT we really didn't encourage you to do. We encouraged you to be very silo-focused, and now we're asking you to really think of the entire system.

Start where you are, and I think that's really very critical because no matter what you're doing in DevOps, start where you are. Whether you're using ITIL 4, you're not using ITIL 4, you're using SRE, or you're not even in service management at all, you have to start somewhere, right? And starting where you are actually makes some sense.

Collaborate and promote visibility. That's very much a Lean way of thinking, right?

Keep it simple. One of the problems with ITIL, I've been in the ITIL space a long time, is it became a little religious, right? You had to sing a hymn before you opened up the books, right? And unfortunately, it did become a little chapter and verse, right? And we didn't keep it simple. It was never meant to be complex, right? But we didn't keep it simple. So ITIL 4 is reminding us that simplicity is actually the fastest way to improvement, and so we want to be able to do that.

And then optimize and automate. And I think in looking at version over version, we've automated the rest of the world. We just forgot to automate ourselves, and I think that's important as well.

So if you kind of look at the Three Ways in ITIL 4, you can see where we can start to see collaboration and promoting visibility is a little bit of that First Way, right? If we collaborate better, if we're more visible, we can increase flow, right?

The First Way looks at something called the theory of constraints, where you pull out your constraints, right, your bottlenecks, your obstacles, so that you can start to increase flow. Well, the best way to do that is through collaboration, right? So we absolutely want to be able to do that. And promoting visibility means we're really comfortable with transparency, right? You can absolutely be much more transparent over that.

We start to look at the Second Way, feedback, right? We absolutely want more feedback.

And then, of course, in the Third Way, if we're going to optimize, we want to be able to become masters through optimization, automation, and ongoing practice. Okay? Everybody good so far, right? ITIL 4.

So now I'm going to move and talk a little bit about SRE. And by the way, I could talk about SRE, I could try to talk about SRE. There we go. I could talk about SRE for a long time, so if you come up to the speaker's room, happy to talk to you. It's a bit of a passion project, mostly because SRE is not the counterbalance to ITIL. It really actually reinforces a lot of practices in ITIL, but in some ways, in alignment with DevOps.

And you have to understand that SRE did not grow up from DevOps. It isn't even the same community, right? It grew up out of a book that was authored by Google. You're not Google. That's okay, right? But it spawned not only a series of principles and practices, it spawned a new job.

Where are my SREs in the room? A couple of you said you're SREs, right? Next year at this time, more of you are going to raise your hand. It is an active job that's being hired because Google was able to define what their SREs look like.

So again, you can get the book for free online. You can buy it off the O'Reilly site or the Amazon site. It's pretty healthy.

Stephen Thorne from Google is here. Is Stephen in the room by any chance? He is going to speak a little bit more about SRE and can tell you more about the principles. I want to relate it to service management. So that's part of my goal.

So look at these principles. You're going to operate against service level objectives. Sound a little familiar, like service level management? But the objective is not an SLA. It's a negotiated set of service levels.

And by the way, service levels are not what happens when something breaks, like we get there in four hours, and we fix it in eight. That's not a service level. It's really levels of availability. It's really understanding what are you committing to in terms of the reliability of this service. Keep in mind, SRE: site reliability engineering.

You start to look at some of the other principles, the ability to regulate your own workload. Now, for those of you, that may be very attractive. For some organizations, it may be a little scary because we are used to micromanaging, and this is much more of a self-regulating environment.

But then look at the next one. You have to have time to make tomorrow better than today. So one of the key principles around SRE is the reduction of toil. You know what toil is. It's all that manual stuff you do over and over and over and over again. The goal of an SRE, because they're an engineer, is also to be able to figure out, if you have to do it more than once the same way, let's figure out if maybe we can automate it. Is there something we can do to make that go faster?

And then failure is an opportunity to improve. That's very much a DevOps principle as well. Fail fast. In the past, the word fail wasn't in our vocabulary. And we don't want you to fail, but we want you to be able to learn. And sometimes the only way to learn is through failure.

So if you look at SRE, and there's some really great concepts in SRE. Again, I could talk about this for a very long time. Things like an error budget. So change management is managed through error budgets. I'm going to tease you a little bit about it at the end.

But if you look at how this relates to the Three Ways: service level objectives, managing against an SLO, in many ways, is an ability to increase your flow, because you know what you're trying to achieve, and in order to be able to achieve it, you have to go faster. You have to identify where are the constraints in your environment.

If you start to look at the ability to manage your own workload, and I want to see what they're-- It's showing us now, good. To be able to regulate your own workload, then feedback is happening always. Always.

So if you're regulating with your team, and SREs, by the way, in many cases, are embedded in dev teams, which is fantastic, so it's not a separate silo that gets passed off to. Ratio is not necessarily one-to-one, depending on the environment, but you're having ongoing feedback because you're a part of the process, and I think that's important as well.

Time to make tomorrow better than today. Imagine having your director tell you that 50% of your time is going to be spent on making your life better, which means SREs are directed to only spend 50% of their time on reactive work. Sounds pretty good. Which means 50% of the time you get to play. You get to play. You get to practice, you get to experiment, you get to do some really interesting things because you have to make tomorrow better than today.

And then if we look at failure as an opportunity to improve, that's practicing mastery. You only become a master when you can practice, and sometimes the only way to do that is by practicing or trying something and failing, or trying something and succeeding. Let's not make it all negative.

So the crossroads, really, between ITSM and DevOps, just to kind of bring it back to where we are, is really at change management. Are you feeling a little bit of that, "I don't know. Everything has to go to the CAB"? Which, by the way, was a mistake. Not everything needed to go to the CAB. A lot of organizations interpreted it that way.

Two weeks before, you put in a request for change. The CAB approves it, it goes back to you, when it could've been a two-minute release. Anybody feeling that pain? A few of you. That was never the way it was meant to be. ITIL very much suggested change models.

Well, but if we look at ITIL 4 against SRE, again, one's not better than the other. It depends on your environment. If your environment needs to have more governance, which means you do need some type of regulatory control, ITIL 4 says, "That's great. Save the big, ugly changes and send them to the CAB." But you can also do some peer-to-peer review. You could do some continuous delivery, which is automation. So ITIL 4 is not necessarily pushing the CAB.

But it is saying risks have to be properly assessed, changes have to be authorized to proceed, and a change schedule has to be managed. That still remains in ITIL 4. So there is a heavy emphasis on governance. But again, in some environments, that's important.

In SRE, it's a little bit different. In SRE, you get an error budget, and the error budget is the difference between 100% and what you've negotiated. And folks from Google, and SREs from-- Starbucks calls it Starbucks Reliability Engineering. But they will tell you that the budget is meant to be spent. It is meant to be spent, which means you can make changes at will.

Now, there are thresholds, of course, and there are consequences of blowing your budget, the same way that there are consequences of blowing your personal budget. And I look as my son's sitting here. There are consequences of overspending.

So if you overspend, there are going to be things that happen that are not necessarily going to be what you want or expect, and some things are going to slow down. So you're given the ability to self-regulate, but on the other hand, you certainly do need to have those policies and consequences set along it.

Again, a quote from the SRE book: "As long as the uptime measured is above the service level objectives, as long as there's error budget remaining, new releases can be pushed."

Now, could you do both? Absolutely. Could you give some teams who have a good track record an error budget, some teams or some products have to go through the CAB? Absolutely. It's not a one or the other.

So regardless of the framework, we have to take an agile service management approach to our ability to manage services. So I said shamelessly, I am the author of The Agile Service Management Guide. So again, if you want a copy, you're welcome to. It's not meant to replace ITIL or SRE. It's really an approach to process design that takes a page from software development, where you build your processes incrementally and iteratively, a little bit at a time, and then you get feedback about it.

The question is, how much is just enough process? And that's the other question you have to ask yourself regardless of framework. How much change management do you need per product, per enterprise, per value creation? How much of it do you need? And how do you know? How do you know? And so that's part of agile service management.

Okay. Just to kind of stay on time, not something easy for me. I always say I can't say my name in two words. I really want you to walk away with some impression of how to put this all together.

First of all, if I leave you with nothing else, please make sure that the religious aspect of either framework goes away. They're not religions. You don't have to defend the realm of ITIL, and you absolutely don't have to defend SRE as being the cool new shiny thing on the block. They are not mutually exclusive. You could take pieces of all of it.

One of the things about DevOps that's really fascinating is DevOps doesn't try to be better than anything else. If you look at, really, DevOps, it takes some Lean value stream mapping. It takes some service management. It takes some automation, people, process, and technology. It takes a lot of human pieces. So DevOps is more like a super framework.

So first of all, never ever think you have to defend the right to have ITIL or SRE or either above. You could do a little bit of both, and if we map the principles together, you actually will come out with a heck of a great service management framework, which will be unique to your organization.

Start where you are: ITIL. Focus on value. Increase your flow from left to right. There's part of the Three Ways.

Self-regulate with consequences. So trust your staff, trust yourself, give yourself the ability to self-regulate. Don't do anything stupid if you are self-regulating. Don't become a badass just because you're given a little bit of freedom to do that.

Make tomorrow better than today. Nothing wrong with that. Failure is always an opportunity to improve. Again, regardless.

Experiment. One of the coolest things in DevOps is you are now encouraged as part of your job to experiment, and some experiments will go really well, and some won't. That's okay. It's really okay. Be comfortable with experimenting. Stretch your mind out to be able to do that.

And then look for minimum viable process. Start there. You would do minimum viable product. Why not start with a minimum viable process and work your way up? If you have a really complex change management process, take it down to minimum viable, and then start adding the layers after that.

So again, I wish I had more time to elaborate. I will go up to the speakers' lounge. So if you have individual questions about how to make this work or you just want to moan and groan about change management, I'm okay with that, too.

I do encourage you, though, to go up to the DevOps Institute website. As I said, our membership is free. We have a lot of great assets. More importantly, we want to make the community interoperable because you are humans at DevOps, and DevOps can't happen without you. Go get our socks. They're good for your soul.

All right. Thanks very much. Appreciate it.