Kaimar Karu

So the session here will be about ITIL, and why what you think ITIL is, is probably wrong; what ITIL actually is, and what ITIL actually says; what are some of the anti-patterns in IT service management and ITIL; and how ITIL and DevOps fit together.

I work for a company called AXELOS, and Gene mentioned the company today on the stage as well, in the morning. We took over the management of the best-practice portfolio from the British government roughly three years ago. That portfolio includes products like ITIL and PRINCE2. I'm the head of product strategy and development at AXELOS.

When you go to various DevOps events or Agile events, then you hear these stories about all this amazing success and things people have done, and how they have succeeded. Sometimes the story there is, why haven't you done those things? Right?

Because when you come from the startup world, you don't have any of the old stuff or the legacy stuff, and then it's a reasonable question to ask: so why have you been doing these things which are maybe not as efficient today? Right? And that comes to understanding or appreciating the context.

There's a story about a Chinese emperor some time ago. When people were complaining that there's nothing to eat, there's no rice to eat, they're starving, his answer was, "But why don't they eat meat?" Right?

So it's quite important to understand the context, and you shouldn't feel bad when you hear stories about other success, and you have something which is not as shiny, maybe.

There are some stories about the transformation as well, and then sometimes when people come in and talk about the transformational activities and how they have changed the way IT works, they talk about the new practices and what they have done. The point, again, very often is, well, these things should have been done a long time ago, so why didn't they do them? And then maybe it's like, I came in and I saved the day.

But let's think about software for a moment, and software delivery.

Some time ago, when people bought applications to install on their laptops or computers, it came on the five-inch floppy disk, then the smaller floppy disk. Then you could download this from your local network. Then you could get it on a CD. Now most of the stuff comes from the cloud.

With good internet connection and the cloud, it's not that difficult to download something which is hundreds of megabytes, or even a few gigabytes. Imagine that being delivered on the five-inch floppies. Right?

So the things we can do today, thanks to cloud and other practices out there, are a little bit different to what was possible in the past. And then when we talk about what we did in the past, we optimized the process, we optimized the service, we optimized everything to match with the requirements of that day, what was possible then. But very often, when doing that, we kind of lost sight of why are we doing these things.

When we talk about process management, and in ITIL, processes have always been mentioned often and thought of as a very important thing. Sometimes they're thought of as the important thing in ITIL, although they're more to support the capabilities rather than the goal in itself.

Managing those processes, fragile infrastructure, everything failing, everything breaking all the time, lots of effort going into trying to make it all work, trying to keep it from falling over, and then we lost sight of why we were doing these things. And then we added more process, and even more process, and even more process. We ended up with something like this, with lots of processes.

And then from the customer's point of view, it's like, where's the value? Right? Why are you doing these things? Why are you polishing your process? I can't see any additional value from this.

And the users are also confused. It's like, okay, so IT is doing certain things, but I can't really see them working that well, and I have problems all the time. Nothing is working. But IT very often is kind of proud that, well, we have done all these things and we have implemented ITIL. Right?

Some of these anti-patterns have led the IT to appear as the people who say no. Right? So IT operations, or IT service management, or IT overall, these are the people who say no, mostly to changes, which has not gone down so well with its developers. Right?

So what are the key anti-patterns, or the things that we have seen organizations doing which should not really be done?

For instance, the by-the-book ITIL implementation. Right? Organizations look at the ITIL library. The current edition is roughly 2,000 pages, and what they try to do is they try to implement it all in one go. It's a three- to five-year project, or so they think, and once they have spent a few years on this, they probably declare this a failure. And then the new CIO comes in, then they do it again.

Also, an anti-pattern is to go for the ideal-world process documentation. So rather than talking to your customers, to your users, and understanding what is actually needed, people spend a lot of time designing processes. And then they print them out, or maybe send to people, and then they expect all these things to work as described because it's sensible people in the company. They all understand that these are the things that should be done. And that never works.

And people get frustrated because, well, we gave you the process. Why are you not following this? But it's an ideal-world process, which was never going to work.

Expensive level-five maturity projects, where the main goal of doing anything with ITIL, or COBIT, or whatever the framework or methodology could be, the main goal is to get to level five. Does your customer need you to get to level five? Are they willing to pay for you to be on level five, especially as your current level most likely is 0.5?

The watermelon SLAs. So these are kind of the reports, or kind of SLA reports, which show that everything is green, but when you talk to your customer, the customer is always unhappy. So green on the outside, red on the inside.

Then we talk about the CAB. So CAB has already been mentioned today, this morning as well, and yesterday. And the way CAB has been introduced to the company very often is a change approval board.

Who knows what CAB actually stands for?

Change...

Advisory. Thank you. Change advisory board.

"Change avoidance."

Sorry?

"Change avoidance."

Or that.

So why have we made it into an approval board? The change manager gives away control and expects people who don't know much about the system they're analyzing to make a decision whether the change should be made or not.

And the success of the CAB is measured by how many changes go through the CAB. So if you can make it so that every change goes through the CAB, the CAB is successful. Change management is successful. And then everybody's feeling the pain.

And then, of course, you have the search for the silver bullet. So be it ITIL or anything else, this is now the solution. This will solve all our problems, all the problems we have had. We implement this. Especially, it'd be really good if we can buy it in a box, so the implementation is done by someone else really quickly. And then the cultural change will just happen by magic because the box also contains 500 pages of process documentation. It's very useful. Always works.

So let's take a step back and then think about why we're doing these things, or what we actually should be doing.

When ITIL talks about services, this is the definition of the service: a means of delivering value for the customers by facilitating the outcomes customers want to achieve.

So to deliver a service, and to deliver a value through that service, you really need to understand what your customer needs. This has been a key part of ITIL for a very long time, actually right from the beginning. It's about value for customers through services, co-delivery, all these things. Yet we have almost forgotten this part, and we have always tried to just, let's make sure that we can implement all those 26 processes. So the focus is in the wrong place.

When we talk about the flow, and that's kind of one of the keywords very often used nowadays: flow. ITIL introduced the service lifecycle in 2007. So the flow is there between the strategy, design, transition, operation. So different lifecycle stages. This is how the flow works.

Things that are omitted too often is the strategy side. But a strategy kind of tells you who your customer is and what they actually need. So you shouldn't be doing stuff because you think it's the best thing to do. You should confirm whether your customer actually needs this. But before you can confirm whether your customer needs this, you should probably find out who your customer is. That's usually quite useful.

Design helps you to figure out what you need to do to deliver that value. And then again, when I talk about delivering value, it's co-delivery or co-creation. It's not giving your customer goods. It's giving them services.

So with goods, the value can be delivered by just giving them something or handing out something. When we talk about services, it's more about co-creation of value. In service management, both parties need to be involved, otherwise value will not happen. Again, ITIL has been talking about this work for quite some time.

We go through transition and operation. And although ITIL has been talking about these things, and as we have on our stand, the slogan we're using is, "ITIL: supporting DevOps since 1989." So the concepts have been there all the time.

But to be fair, again, when we talk about the current edition, it's five books, plus now the ITIL Practitioner. It's roughly 2,000 pages of content, which is all useful and valuable and meaningful. But for most people, it's too much. Reading through five books is a little bit too much. So we're looking at how to make it more digestible.

When we bring the service management discussion and ITIL to the DevOps context, let's look at this slide, what service management actually means. We have the customer on the left-hand side there. We have the customer. The customer has requirements. They talk to the service provider, they negotiate with the service provider, and then at some point they reach an agreement, and then the work can start.

And then the work starts. Let's say when we talk about software services, the work starts with the development team, so the purple one there. Software is delivered, and then it's bundled into a service, and then it's delivered to the end user or the end customer. And that's a simple flow, but that only works this way if nothing ever fails.

When we think about IT systems, do we know of any without any incidents? Yes? No? Probably not.

So the customer or the user probably has a challenge, or a question, or a concern, or something is not working once in a while. So they want to talk to someone, or email someone. This is where the customer service comes in.

Customer service might not be able to solve all the issues themselves, so they might refer them to level two, or level three, or level four. Sometimes those people also can't figure it out, then they refer it back to the development teams, which then feed back into product development, which then feeds back into the service management, and this is how it goes.

So when we talk about DevOps, or when we talk about the practices that are usually covered when we talk about DevOps, that's the red circle there. That's where most of the DevOps practices, or the practices discussed in the context of DevOps, this is where they live.

But that's not enough. Right? Fast software delivery is not enough. Your customer expects more.

When you are using Uber or Lyft, it's not just enough to have the app. But when something happens, when you forget something in the car, or when the driver wasn't maybe behaving that nicely, you want to contact someone to deal with that. That is all part of a service.

The successful delivery of the app is only one part of the whole service. Yet the service mindset very often is completely forgotten.

For those who might enjoy block diagrams more than these kind of things, this is a different view of the same context. When we talk about DevOps and IT service management, what we often talk about is the service transition and operation on the ITSM side, or ITIL side, and then a few things on the software development side.

Some things that should be there, or should be discussed, are very often not discussed, like, for instance, continual service improvement. And that's one of the biggest mistakes the ITSM world has done, is not focus enough on continual improvement.

So everything is a big-bang change, which might or might not happen again when the CIO changes, and the opportunities for improvement is not built into what people do, which means that the moment you release that process, it's already out of date. You have no mechanism to improve it over time. It gets more and more out of date as we go. You keep adding new stuff to that, it goes more and more out of date, more and more difficult to manage, and then you need to go for the big bang eventually because nothing is working anymore.

So continual improvement is a very important part of this. The good thing is both the IT service management side of things and the software development side of things, they all focus on the same thing: delivering value rapidly and continually. So the alignment is perfect. Yet again, these two groups don't necessarily talk to each other.

When we talk about the Three Ways of DevOps, as kind of discussed also in The Phoenix Project, this is one example of one view of how that relates to ITIL and IT service management.

So we talk about the flow, and the flow is from left to right. So we talk about strategy, design, transition, operation, from the customer requesting certain services to value delivered to them, to value delivered to the users on this end. And then the feedback through different processes in ITIL goes back from operations to transition to design to strategy.

And then around all of this, you have CSI. Right? CSI that brings up the opportunities for learning and improvement through all these services, through all these processes.

So in the service lifecycle, again, as introduced in 2007, the concept of flow and feedback is already in there. But what organizations very often have focused on, because infrastructure was failing, is parts of this. So most organizations have incident management. Some have problem management. Almost everybody has change management, which usually means a CAB, which needs to control all changes. Right? So there's lots of inefficiencies in there.

So the end goal, or one of the end goals we see, is to move the operation side of things to behave as a service provider as well. This is one of the end goals, how things should be aligned.

So you have the alignment between software development and IT service management. You have DevOps practices throughout the value chain, not just on the operation-transition side, because DevOps very much is a philosophy more than anything else. A philosophy that has inspired many very good practices to evolve.

And around all of that, you have the CSI, or continual improvement, but you also have quality and security assurance. Right? So this is one of the directions to go.

But again, just going through the 2,000 pages of ITIL content might be quite difficult. So earlier this year, we published the ITIL Practitioner Guidance, which is like a sixth book of the ITIL library, which is written in a slightly different style.

And one of the things that we discussed there are the guiding principles. So when we were writing the ITIL Practitioner book, which was meant to help people to start adopting and adapting ITIL, we were looking at ITIL and Lean and DevOps and Agile, and we found that many of the principles are more or less the same across all of them.

So we went through the ITIL books, and we brought out the key principles, or the guiding principles, we believe help organizations to improve IT service management, to get from where they are today to a somewhat better position.

So we can't give you a direct answer, because it depends on your context, but these guiding principles help you to assess various options, various solutions, and to find your best match.

So we have nine of them total.

First of them is focus on value. So whatever you do in IT service management, you should focus on value. All activities you do must deliver customer value, not value for you, but for your customer. And it's the customer who decides what is of value. It is not you doing it for them. It's them who tell you what is valuable.

And then not all improvement actually delivers value. So the fact that you are upgrading something, be it software or hardware, unless the customer actually benefits from that upgrade, you're wasting your time and their money. If you can't link your activities, your improvement, to customer value, you shouldn't do it. There's no justification for you to do that.

The second guiding principle is design for experience. So you need to understand the interactions, how your users, how your customers interact with the services that you provide. How do they consume those services? You need to walk a mile in their customer's shoes.

It's not just asking them about these things, but you should observe as well. And then empathy is key. Try to understand what they want to achieve and how you can make it easiest for them to achieve their objectives as a service provider.

You should start where you are. So you need to understand the vision and the direction of the organization, of the IT organization as well. You should seek out the value in what you already have. So it's not about throwing everything out and then starting from scratch, because that is rarely successful.

You probably have many things in place that are useful, but they might be currently in the wrong context. So seek out what you have of value and make use of that. Leverage what you already have.

When you're doing these things, you should work holistically. So it's not just your improvement or your activity here, or your team, or maybe your department. You should look at the whole organization if you're an internal IT service provider, or at you and your customers if you provide external services. So holistic view.

Organizations are complex systems. If you tweak something here in this corner, and you think it only affects you, you're probably wrong, because a small change somewhere might have a huge impact somewhere else.

If you don't understand the end-to-end value flow, if you don't understand the whole picture, you are quite likely to lead yourself or your team to local optimization. Something that looks good on paper for your team but actually delivers no value for the organization, and might actually go against delivering value for the organization.

So local optimization does not mean value delivery. And as I said before, value is co-created through interactions when we talk about services.

You should avoid big-bang change initiatives. Think about smaller, manageable changes. Keep improvements manageable, keep them small, and keep delivering value continually. Do not hold back delivering value.

So in IT, or in software, in most cases, you shouldn't really go for the waterfall approach where value is delivered in two years' time. With most things in IT, you can take this approach to take small incremental changes, updates, improvements.

You should also observe directly. So you need to understand what the context is, how your customers behave, and why and where. You should favor direct observation over just reports.

So if you go and see how they work, it is more useful than just reading a report because, as I said before, the watermelon SLA reports, they don't give you the full picture. So go and observe. And then if you go to the source, it kills assumptions. You might assume how certain things work, but before you go and watch, you don't actually know.

You should also be transparent because the unknown is scary for people. When there's information missing, it's usually replaced by something else, by misinformation, which most likely will lead you into trouble. So to avoid that, being more transparent usually helps.

And also transparency creates supporters for your cause because when you think about improvements, when you try to make them in your organization, you need to have champions. You need to have people who support you across the organization. If you don't understand who your stakeholders are and how they can help you, you will be alone and quite likely to not succeed.

You should also collaborate within your team, with other teams, with the rest of the business. You should work directly with your customers and users, and you should really manage your stakeholders. But before you manage your stakeholders, you need to understand who they are.

And the last guiding principle is keep it simple. We're talking about the minimum viable process. So do not create massive process documentation. It doesn't help anyone. And please ask your consultants to stop doing that as well.

So minimum viable process, minimum viable procedure, and minimum viable reporting.

Again, all these things, they're hidden in ITIL, in the five books. We have now brought them out in the ITIL Practitioner guidance to help you to start the proper adoption and adaption journey and improve your services.

At our stand in the expo hall, we have the small booklet with the guiding principles, which is a part of the ITIL Practitioner book. And we also have there a free copy of the How to Use Kanban for IT Operations guidance paper. So if you want to understand how you could leverage Kanban in IT operations, not just on the development side, come to our stand, pick up a copy.

And if you have challenges with adopting ITIL, if you have horror stories to share or success stories, then also please come by. Talk to us, share your stories, and we will help you in any way we can.

Thank you.