Kaimar Karu

Good afternoon. Today it's going to be me and Akshay, my colleague, talking about ITIL and why I believe that what you think it means is not what it actually means.

We come from AXELOS. AXELOS is an organization that took over the management of the best practice portfolio four years ago. So we took over the management of ITIL as a product four years ago. We have been developing it since, and last year we released ITIL Practitioner Guidance as a new addition to the ITIL library.

Starting from where we are with IT. IT has gone through a pretty significant journey over the past 10 to 15 years. When we think about the way software is delivered to individuals, to organizations, we started with a five-inch floppy. Then we had a three-inch one. Then we installed things from our local network. Then we installed things from CDs, and now everything lives in the cloud, so we just download it and install it.

And the journey has meant that we are now able to do things faster. Sometimes, when you go to DevOps events, the discussion is, "Well, we have discovered these new ways of doing, and you should have been doing these things for a long time already. So now we can release thousands of times per day, and why haven't you figured it out before?"

I would like to see an organization that is happy to release new software on a five-inch floppy disk 10,000 times a day. Doesn't really work, does it? So we need to understand the context and why things are the way they are and why things were the way they were.

For instance, like Emperor Hui. At some point, his people came to him with, "Dear Emperor, our people have no rice. We're starving. We have no rice to eat." And Hui's response was, "But why don't they just eat meat, then?"

Right? The understanding of context, understanding of a challenge. If you don't have rice to eat, you probably don't have meat to eat either. But if you live in an ivory tower, you don't understand the context. So when we talk of the improvements, context is the key.

Because of various challenges IT has had over time, IT has this image in many organizations as the people who say no. When we talk about IT operations, these are the people who say no to developers and everyone else. When we talk about IT overall, it's the rest of the business who comes with ideas and questions and challenges, and IT just says no.

You probably have all experienced this, or you have been the people who have been saying no for the rest of the business, and there are reasons for why that has happened.

When guidance was sought on how to make things better, in the context of really expensive hardware and the long time it takes to get new hardware in, the reality of software that keeps breaking all the time, and then the customers are always unhappy about that. In that context, what can be done to make things better? This is where things like ITIL originally came in.

Sometimes IT seems to work, sometimes it doesn't. What's the difference? What are the practices that help to improve this?

What has happened at the same time is, for a long time, the focus has been mainly on the process side of things, forgetting about why ITIL was put in place in the first place. Lots of focus on process as if the process is some kind of magic dust, or just magic, that once you put the process in place, everything just works.

Doesn't work this way.

Different ways on how to handle the fragility of IT have also led to these kinds of issues. We have all seen by-the-book ITIL implementations, right? We need to put in all the 26 processes in the next three years, or quicker, because once we get them in, everything will just be perfect.

Or the main thing that we need to do as an organization right now is we need to write down our processes in the best worldview version of that process, which then gets documented in 120 pages and put on a shelf, never to be looked at again. We have seen those things.

We have seen the very expensive level-five maturity project. "We can't compete with anyone else unless we get to level five," right? CMMI level five, which again is another five-year project, which might be extremely relevant and useful for the consulting company that does it for you, but not necessarily for you.

The watermelon SLAs. The SLAs being used to show things that are nice to show rather than things that the customers really care about. The watermelon SLA is something that is green on the outside and red on the inside. We have seen those reports. All the SLAs are green, but the customers are extremely unhappy. What is happening there?

We have seen CAB being used as Change Approval Board rather than Advisory Board. It was meant to be Advisory Board, to help people to figure out, if you have a really complex change, who do you need to talk to, to figure out who will be impacted by this, and does it even make sense to do it?

Instead of this, it became the approval board. So all changes of all sizes went through the CAB, which means that everything is delayed by two weeks or four weeks. You get a bunch of people who all mean well, but they have no clue about what it is that they're discussing there or assessing or evaluating, which brings a lot of pain to everyone, including those people on the CAB. Nobody wants to do that, but you have it in place. Approval board: unless they stamp it, you can't make it.

And then the search for the silver bullet that is always there. We want to have this one solution that solves all our challenges, and 15 years ago or 20 years ago, very often ITIL was sold as that solution. Whatever your problems are, just implement ITIL to maturity level five in three years by using our services, and then it will all be fine.

We have seen organizations around the world who have tried that and failed. We have also seen many organizations who have tried to put this in place step by step, adopt-and-adapt approach, and they have been extremely successful in that.

So it can be misused, and it has been misused. Because of the misuse, ITIL in many organizations has this kind of bad name. ITIL means that it's slow. It means the CAB. It means the process focus and all these things.

Because of those things, organizations were like, "Okay, so we have all these processes in place, and IT comes to us with, 'We now have implemented problem management to level three,' and they seem to be so excited about that problem management thing. Whereas as business, what's the value? What am I getting from all of this?"

No clarity.

So the business was like, "Okay, IT kind of doesn't make sense anymore. It's still a black box. It's just a cost center, and if we can get it cheaper somewhere else, we should do that. So let's see if we can maybe outsource the whole thing, get rid of the problem." IT is the problem, obviously.

The same way as IT thinks that users are the problem. So it's like this, mutual.

To go back to the basics of what we're talking about when we talk about ITIL and service management, we talk about services, and this is the definition of a service from the ITIL books. A service is delivering value to customers for their outcomes.

One of the things that is very often misunderstood in this context is whose outcomes. Many services have been designed to deliver outcomes for the service provider, not for the customer. Something that looks really cool, design-wise, as a process or as a service, is actually completely useless for your customers.

So where should the focus be? The focus should be on the customer and the value that they require, or the value that they are interested in.

In the recent few years, as AXELOS, we have gone back to the basics and tried to bring out a few things about services and service management that should help organizations to also go back to: why did we even introduce ITIL five, 10, 15, or 20 years ago? What was it that we wanted to achieve? What are the things that we might have in place today which made a lot of sense 10 years ago, but we don't need to do these things that way anymore?

Adrian Cockcroft calls some of the processes in organizations scar tissue. We have had issues with technology over time, and we have put some processes in place to help with those things, some procedures in place. But maybe we don't need to do the exact same things anymore. Maybe we can be more efficient. How to become more efficient? We need to go back to the basics of why we're doing things.

When we talk about the ITIL lifecycle, for instance, there's the strategy part, where we talk about how to figure out who the customers really are and what they need. We talk about the service design part, where you need to understand, as a service provider, what capabilities do you need to provide those services to the customers and how to build them.

We go to transition, where you actually build and test and deliver. And then on the operation side, how to maintain that, how to run that, and how to make sure that the customer experience is really, really good.

This is very easy, but not that easy to do, right? On one slide, it's very easy.

There's another view on service management. It starts with the boss man or boss lady on the top left. It might be a business unit manager. It could be the CEO. Whoever it is who has some requirements, or something they need or want from the IT department or from the part of the organization who delivers IT services.

They talk to the technical teams, go through the checklist or wish list. At some point, they shake hands, and then the real work starts. Everybody gets involved: the users, the developers, the operations professionals, the service management professionals. Together they create that service. And if they're really smart, they create that in an iterative way, so they start delivering value in small steps.

Then you have the end user who will be consuming that service, and all is fine. That's a very simplified and simplistic view of the world of service management because, as we all know, once you have released something and the users can now access this, that is not enough.

Sometimes they have questions. Sometimes things break. They need to call someone or email someone, or maybe even register a ticket, or an incident, or a service request. So there are some things that need to be behind this to make it work.

You have the call center or the service desk, for instance. They should be able to help with the most basic questions. If they can't help you, then you go to the second level or third level of IT operations professionals. You talk to them. You ask them how to help the customer. It flows back to the customer, and the customer feels good because now it's working again.

Sometimes, it's not just enough for operations professionals to work on things. They also need to involve the developers, and they need to figure out how to fix that bug. Again, they do that. They improve the service. The users are happy. And then, if all of this flows properly, there's going to be money going back to the boss man, and they will be happy as well.

This is an idealistic view of how service management should work.

What has happened very often in organizations is we have created these process silos. We have the incident management team, and we have the problem management team, and change management team, and release management team, and capacity management team, and so on.

Because they all are professionals in their field and they believe that their topic or subject or process is the most important one, obviously, then talking to other teams is not really that great activity. They don't want to do that.

So we have these silos. When something happens with a service, it needs to flow through all these silos of different teams who all think that they know what they're doing, and they do in their context, but not necessarily in the overarching context of that service, which leads to many issues, delays, and pain.

One way on how to solve that, or start thinking about how to solve that, is to organize not just for products, but to organize for services. Rather than having your different silos for incident, problem, and so on, the same way as we're talking about the product teams, we can also talk about the service teams.

We have people who are responsible for the strategy and the design and operation and transition and software development, all of them in one team, not focusing on pushing code out, but focusing on delivering a valuable service for their customers.

And then to support those teams, you can have the platform services, for instance, for technical operations or vendor management or the service desk. If your organization, let's say, has 120 services, then it probably makes sense to have one service desk to cover them. Because if something goes wrong and your user wants to call someone to figure out what's wrong, they either have a choice of calling one number, or they have a phone book of 120 numbers, and they need to go through all of them one at a time to figure out which team is responsible for that service.

Most customers don't want to do that. Maybe some do. I don't know. Most customers don't.

Essentially, how to move from where we are today with IT service management and the way ITIL has been used to something that would actually be more useful in today's world. How to improve the way you do ITSM, or improve the way how you can adopt and adapt ITIL.

As I mentioned before, we came out with the ITIL Practitioner Guidance last year, and one of the parts of the guidance is the guiding principles. There are nine guiding principles. I'm going to go through them.

This is going back to the essence of what ITIL has been saying from the beginning, but maybe with something that was hidden behind the layers of process models, maturity models, implementation projects, and all these things.

All nine guiding principles are equally valid. They all apply at the same time. But they have numbers here because they're on slides, and one slide follows another, so numbers.

First one: focus on value. Key thing here, it is the customer who decides what is of value. So it's not the service provider. Also, when a service provider, the tech team, changes things or adds new technology, they might think it's an improvement, but actually it's only nice for them and not for the customer. So not all changes, not all improvements are actually improvements.

The second one is design for experience. You need to understand the interaction between the service provider, the service, and the customer. If you don't understand how the value flows there, you will struggle with figuring out how to improve the right things, rather than just spend money on things that don't matter.

You should start where you are. Understand the vision and direction of the organization, but also the improvement initiative. You should seek out value in what you have. That's processes, people, services, whatever you might have, rather than come in with, "We are now running this DevOps project." The same way as we ran the ITIL project five years ago. How did that go?

Try to figure out what you already have, what is valuable, and then leverage what you have.

Working holistically. Organizations are complex adaptive systems. You need to understand that, and your actions need to be based on this understanding. Very often, we have seen local optimization, which again, it delivers value on paper maybe for your team, but the whole organization and your customer might not get anything from this. Or in the worst-case scenario, your local optimization is messing everything up for everyone else.

CAB, as a Change Approval Board, is a local optimization. It's a terrible idea that looks good on paper for some. Never really works the way it was meant to be.

Progressing iteratively. When you talk about changes and improvements, try to avoid the big-bang changes and go for something that you can deliver continually, and try to keep the improvements quite manageable if you can.

Observe indirectly, which is a Lean principle. Rather than guess what your customers think or want or need, or how they use your services, go and talk to them. Your customers, your users, are also nice people, the same way as you are. So it's actually quite okay to go and see how they do their work. So when you improve, you have the context. If you don't have the context, you probably improve something for you, not for your customer. It might look good, but nobody cares.

Being transparent. The unknown is scary. If you think about improvements, if you don't bring people on the journey with you, they will start making assumptions about what is happening.

When you talk about knowledge management, for instance, "So you want me to document things because you want to get rid of me, right?" So you need to explain to people why you are doing these things.

Collaboration across different teams, across the whole value chain, IT, non-IT. Because IT service management will never, ever work properly if it's only done in and with IT. ITSM, IT service management, means that you need to work with the rest of the organization.

And lastly, to keep it simple. When you design processes and services and procedures and everything else, minimum viable, or minimum valuable, process, procedure, and reporting. Start with that. Don't go for level five immediately because that doesn't really work.

These are the nine guiding principles which we have brought together as the basics from ITIL and how it links back to things like Lean and Agile and DevOps as well. To create the links for organizations to understand how all these things fit together. They're all explained in more detail in the Practitioner book as well.

Nine of them, really valuable. They all apply at the same time, and you can look at them as your enabling constraints to make sure that you deliver the best services you can and you keep improving continually.

Going to now hand off to Akshay.

Akshay Anand

Kaimar talked about extending the concept of minimum viable. We're all familiar with minimum viable product, and there's obviously minimum viable product management: the basics of capabilities you need to develop your roadmap, your vision, your stories, et cetera, et cetera.

If we buy into the concept that services matter as much as products, or products are a combination of goods and services, then we also need to think about minimum viable service. How are users going to interact with the service? What sort of service are we developing for them? What's a minimum service that they will want to consume?

And equally, what is the minimum amount of service management that we need to put in place? Do we need to put change management in place first? Do we need to put some sort of incident management in place first? So rather than trying to boil the ocean, which is part of the level-five multi-year consultant journey, think about what's minimum viable service management.

You can apply the same techniques or approaches that you have in normal product management and product development to service management.

As Kaimar mentioned, as part of the guiding principles, you start where you are, define your vision and what you want to do to work towards it, and then through a series of iterations, which can be the same cadence as your development teams, start working out what changes you need to make. Small changes that improve the service, that improve the service management at the same rate of progress as your product or your digital goods or software goods are developing as well.

Now, one of the things...

I apologize for rushing. I know we've got the keynotes going on in about...

And a mic change as well. Testing, testing. Is this working? Yep. Okay.

We've got the keynotes in about five or 10 minutes, so unfortunately, I'm going to have to rush through this. But I will be at the booth, and I would love to talk a bit about this more if people want to.

One of the things I heard in San Francisco last year was a lot of IT service management professionals saying, "This is all great. DevOps is great. Three Ways is great. But what do I need to do with the ITIL investments I've made to date? And how do I make sure I'm able to improve them and allow my development teams and my DevOps teams to flow faster, to get feedback faster, aligning the service with the product?"

So I'm going to try to show you some of these processes and how they align with the Three Ways in a few slides in five minutes.

The big question to be asked is, does the product team's ability to deliver something align with the service organization's ability to manage that? Does my product team's ability to deliver software increments align with the service organization's ability to manage changes to the service, or release the increments, and so on?

ITIL and the Three Ways.

One disclaimer before I go to this: as Kaimar mentioned, ITIL's a lifecycle. All the different processes interact with each other. Great, brilliant. What I'm going to be talking about is where you need to focus your attention first, and then move on to other things. What are the low-hanging fruits, essentially?

When we talk about dev in the DevOps context, and looking at it from an ITIL point of view, we want to make sure that release management, as well as service testing, is aligned with release management from a development team, as well as whatever technical testing that your development organizations are indulging in.

From an ops perspective, operational capacity, event management, incident management: is the technical ability to do these aligned with the service organization's ability to do this?

First Way: the flow from dev to ops. Three processes that I would suggest you take a look at first. Change management. We've all heard about how CABs are black holes of where hope goes to die, but it can be better.

I've been exchanging quite a few tweets with some of the attendees of this conference. Keep in mind that the CAB is supposed to be the Service Change Advisory Board, not your Technology Change Advisory Board. That's where ITIL started. It's a service management concept.

Configuration management, which is related to configuration management at a technical level. But here with ITIL, with IT service management, we're talking about managing the relationship between your service assets, your service components. And so when you deploy a change, do you need to change your CMDB? You might not, but if you do, make sure you've automated that and you have the linkage there.

And last but not least, knowledge management. Is there enough release notes? Is there enough documentation that your technical operations teams can continue to work and maintain the system that's been put into production?

There is one more little loop that goes back the other way, which is still related to the First Way. This is not the Second Way. One of the things that The Phoenix Project and The DevOps Handbook talk about is making sure that your developers are developing in production-like environments, and they have access to the right environments.

That's a flow of value from operations back into development. So although it looks like the Second Way in feedback, this is actually part of the First Way.

Moving on to actually the Second Way, incident management is the first place I would take a look at optimizing.

And then the Third Way: continuous improvement. We've got CSI as a process in ITIL, which I think is vastly underfunded and neglected. But equally, we've got problem management. Why did something work? Why did something not work from a service perspective, from a technology perspective? Use problem management and problem management techniques to get to the root cause of not a technical error or a technical issue, but the root cause of a process issue, of a capability failing.

But wait, there's more.

Service operations and the Three Ways. You've got dev and technical ops, but you've also got a service ops organization, especially in these large enterprises. Your service ops is typically your service desk. It's the people taking the calls from your end users, taking requests from your end users. Your DevOps teams need to be able to interact with them in a similar way.

There needs to be a flow of knowledge going down to your service desks, whether that's release notes, whether that's FAQs, updated support scripts. That needs to flow. Going back the other way, the service operations teams need to be able to identify problems, need to be able to escalate incidents. They also need to be able to, if appropriate, send requests back straight to development, such as requests for new features.

And again, Three Ways. CSI, problem management, figure out why problems are taking place, how you can improve the service and the flow and the Three Ways, and so on.

But wait, there's more.

Service design and the Three Ways. Now, I initially wanted to call this service development, and I got slapped down. So we've got dev and ops, and we have a service design organization where the service is actually designed. We look at things like resilience. We look at security. We look at disaster recovery, continuity, and so on.

These guys need to be able to... The flow of value from service design into dev is your enabling constraints. It's what does the system need to be able to do? How many transactions per second? What does security need to look like? What does capacity need to look like, and so on.

Development needs to be able to send performance information and metrics back into the service design organization. But similarly, your technology operations needs to be able to do the same thing so that service design can continuously improve and feed better information into your development operations teams.

Now, why have I rushed through this in the last two minutes? Well, Kaimar talked about global optimization versus local optimization. What we're essentially trying to do at the end of the day is that the business units are trying to interact with the customers, provide them with a valuable product and service, get valuable feedback, whether that's revenue, market share, whatever, and continuously improve the way they're delivering that service to the customer.

But in order to do that, they've got to go through service design. They've got to go through development, development to ops, ops to service ops, and the service ops are the ones who are actually directly interacting with the customer.

If you take this view of the value loop, then what you're looking at as DevOps is really the biggest local optimization exercise that we've seen in a decade, I would say.

This goes back to work holistically. Don't focus on just DevOps. Understand the flow of value from the business to the customer, going all the way around this loop, and therefore optimize globally, not locally.

And yes, on time.