Aligning ITIL 4 With Other Frameworks Such as Agile, DevOps, SRE and Lean – SKILup Days 2024

Good morning everybody. Um, uh, welcome to this session of, um, of the, um, skill Up Day. Uh, so today what we're gonna be doing is actually talking about aligning ITIL four with other best practices.

So how does it four actually aligns and map to DevOps as well as, you know, agile, et cetera. And that's what we're gonna be covering today. Um, so this is actually, um, what we're gonna be doing for the, for, for this session.

Uh, so, um, the, the kind of best practices that we're gonna be looking at are Lean, agile and DevOps and, uh, sites, reliability engineering. So what we're gonna be doing, we're gonna first start with an intro for each one of them, uh, just to make sure everyone is on the same page. And then we're gonna go to the ITIL full part.

And then we're gonna bring back some of the information that we have already covered in the individual kind of overviews of these topics, uh, and show you how we, how ITIL is actually aligning to them, uh, and so on, right? So, to get started, I just am gonna give you a bit of a background about myself. You know, uh, what's my background, what I've been doing so far.

So as far as my background is concerned, so I've been, I am actually, uh, I am, uh, the co-founder and principal consultant of E two E-I-T-S-M consulting, E two E standing for end-to-end, ITSM consulting. Um, um, I've been in the industry for quite a long time. Uh, so I worked in, uh, the, uh, application side of things, um, in, I saw application development.

I used to be in software culture assurance, and then I moved to the, and, and as part of applications, I actually, obviously, um, the organization I worked with was implementing CMMI, which is the capability maturity model integration for, uh, development at the time. Um, and then I moved to the infrastructure side of things, and then this is when I actually got started into ITIL and so on and so forth. Um, and, um, yeah, uh, and then, uh, and then I got into consulting, obviously.

Uh, and since then, I've been in the consulting, uh, business since about 2000 and, um, nine. Um, so I have a, a contributor to many kind of areas within the industry. So I have been involved in reviewing, uh, standards like the ISO IEC 20,000, different parts of it.

0 when it was before it was coming out. Um, and, and so on and so forth. I've been involved in a lot of, um, activities, you know, behind the scene, uh, within the industry.

Um, I am an, uh, a, a people short IT ambassador, um, and a DASA ambassador as well. Um, I used to be an examiner for it, uh, version three, uh, for the IT operations, support and analysis kind of, uh, exam, intermediate exam. And prior to that, to that, I was actually an exam marker for X in South Pacific for the manager certificate in IT, version two.

Um, and, uh, I, I have been a former, um, uh, board member for I-T-S-M-F Australia. I'm really, really passionate about everything that service management, um, that is organizational, um, management of change and organizational culture, especially, uh, those aspects or related to digital transformation. Um, some of my qualifications.

So this is just a little bit of, of my qualification. Obviously, it's not, it doesn't cover everything. Uh, so originally I used to do translation and interpreting different languages, and then I came to Australia, and then when we, when I came, I actually did my MBA.

And then, uh, after that I've been just doing some professional kind of work and, and certifications and qualifications and trying to, uh, continue. I love learning new stuff. So I'm gonna continue.

My learning journey continues. Alright, so now let's, uh, set, uh, the context. Okay.

So to get started, it all really ev everything we, we know, I believe all best practices that we have been working with over the last, I dunno, how many years, uh, started with lean, actually, okay. So I, it, it, it, it seems to me that it's at the basis of everything we are doing today. So what is Lean, lean started maybe 90 years ago or maybe more, something along those lines.

It's a holistic and a sustainable approach that is all about, um, using less to, to deliver more. Okay? So again, um, it's all about, um, less is more like we hear it now while it's been lean has been saying that for ages by the sounds of it.

Okay? So, um, alright, so what did Lean give us? Lean gave us an ideology that usually that promoted things like unrelenting focus on providing customer value.

Wow, really? Okay. So that has been going on for 90 years.

We are talking about value quite a lot, uh, more recently, but yeah, let's see. Um, okay, respecting people, most of all. Sure.

Isn't that a great kind of environment to work in? You know, taking long-term views, so doing whatever we wanna do, not just, um, uh, to fix something. Now that might actually have side effects over the long term, but we are looking at the long term kind of thing, okay?

Um, keeping things flowing in a value at an effective manner. So again, we are talking here about value add, okay? Um, build building long-term relationships with stakeholders, providing exactly what is needed at the time it's needed as per the customer requirements kind of thing.

You know, reducing variation and elimination and eliminating waste. So, uh, you know, another, you know, how can we do that most probably through automation would be a very good, um, kind of way to do it. And that's what most practices, and most models and most best practices these days are actually promoting automation.

Um, lean has always promoted automation with human touch. So not automation for automation's sake, really. Um, and then using value streams, you know, and value stream mapping and value stream management for actually visualizing what we are doing.

You know, what are the steps that we have to follow, okay? Uh, improving value across the whole value stream. So it's all about making sure if you wanna do improvement, because value streams were creating, were created within lean for the purpose of, uh, continual improvement.

So they would be mapping the, the current value stream for the as is, you know, and then they would be looking at all kind of things they wanna change. And then they will go and map a new, the future or the desired state value stream, and then work out for us to get to that desired state. What do we need to change?

And they will come up with their improvement program, and once they implement it, the future value stream becomes the current and so on. And the cycle restart. So the point here, when we have to, IM improve within the value stream, we need to make sure we improve the whole value stream.

If we improve one step in the value stream, it might actually overwhelm, you know, other steps subsequent to that. And it might actually also affect, you know, predecessors and so on. So these are things that all have been, lean has always been talking about, you know, a continuous learning and everyday improvement.

Again, this is something, you know, in a lean environment, that's what everyone is trying to do things better, you know, on an ongoing basis every day. And we're gonna see examples and, you know, kind of concepts, uh, related to that, that Lean is also providing. And then, um, leading, you know, by focusing on many things or results, how the results were achieved, you know, and how is the customer value being created, you know, and so on.

And then also it is, uh, making sure and, and, and making sure that, uh, capability is built within employees. It is, it does recognize that employees obviously are the main asset, you know, that, um, that any organization has. And it goes hand in hand with respecting people, you know, most of all respecting people.

Alright? Also, lean also gave us the lean culture, which is everything that we'll be talking about and more. It becomes, you know, built, built into how people, uh, do, do, do things, you know, uh, their behavior, their attitude.

It be, you know, it gets programmed into people's behaviors and attitudes. Uh, it gave us also the Toyota production system, which a lot of organizations are actually using. And it's not only for manufacturing.

They're using the same principles and concepts within the TPS to actually do any kind of business. Um, it also, um, gave us, you know, uh, the, the concept of building quality at the source, which is very, very important, which involved, um, the j doca, which is the Japanese word to say, you know, accept no defects, pass no defects, make no defects, you know, so, and then it, it brings the concept of the endon where, you know, if you are working in a, in a line or, you know, throughout a value stream and what you're receiving has some, uh, defects in it, you actually stop the value stream. You, you stop it because you don't want the defect to progress.

Because if you catch the defect at the testing phase or at the inspection phase at the end, well, that unit that you've produced anyway is defective. So it's waste. So remember line is all about waste elimination.

So these are all, you know, mistake prevention, fail safe kind of approaches, right? Uh, which is they called oke, you know? Um, and they don't call, by the way, sometimes we refer to it as spa proof, uh, full proof, sorry.

And they say, no, this is not what we should be calling it because it actually insults the people that we we're supposed to respect. So, um, they call it feel safe actually. So other things they talk about, you know, um, the kaizen, which is continual improvement, gradual continual improvement as opposed to bleeds when you actually have big changes and you have kaku, which is actually when you have radical changes, okay?

Uh, so different types of how you can improve things, alright? Right? So these are all improvement kind of approaches.

Um, they talk about also the, and the gemba is go check for yourself. And gemba is where the action is. Well, if you are familiar with itil, does that sound ring a bell to you?

We're gonna actually bring all this, um, in, in, in the, the, at, at towards the end of the presentation where we actually make all the, the comparisons. And by the way, um, I wanna grab your attention to the color coding. So every one of our topics will have a different color because at the end I'm gonna bring ITIL and I'm gonna actually say, okay, so this is how we ITIL relates to this and that, and what have you.

And the color coding will be showing, this is how ITIL relates to lean, this is how ITIL relates to agile DevOps, et cetera. Alright? Um, so it also bring tax, uh, tech time.

So lean gave us tech time, which is the rate of production that is supposed to be based on the rate of consumption. So again, there's a calculation to how we can work that. And one of the things that can help with it is the Kanban, which are the cards that are usually put on the containers that are used for the purpose of replenishing as, um, the contents of those containers are actually being used.

Uh, but obviously you see we are using that in different ways now. Okay? They talk about value streams and value through the eyes of the consumers, you know, a value add criteria.

They, they went to the, to the extent of actually saying to, to call something value add. It has to have, it has to follow this criteria. And they have three specific criteria, you know, customer is willing to pay for them, uh, you have to get them right first time.

And the third thing is actually related to, uh, it has to, uh, in that step to say that this step is a value add, it has to actually transform your product or a service in certain way. So these are the criteria that they actually use for that as well. Um, they also talk about waste.

They explain, you know, what is the difference between MOORI type waste, you know, versus Buddha versus um, um, Moura, which is unevenness, you know, and, and how to fix it. And with the an, they have something called the Hi Jua Hika, which is about leveling of resources. So, um, and then they do specify different types of waste for people to actually think about.

And the hi jua, which is, um, and they talk about the fives, by the way. And the five s are how you can get rid of waste, uh, through workplace reorganization. Okay?

And, you know, the, the improvement activities associated with those kind of things and how we can get rid of waste and all that are performed not only by, uh, people at the floor level in an organization, the highest level of most senior managers get involved in those activities, just like with, with everybody else. So if we need to, um, improve our organization and get rid of clutter, because this is what this five Ss are related to one of them, and, you know, it's about how can you get rid of clutter, for instance. They have a process for that.

And in that process, in their exercise, their vice president can actually be working with the people and they can go and clean the floors with the people. And so it's, it's a totally, the culture that comes with lean or the lean culture is about, we are all one team. We all work together towards the benefit of the whole organization, which is actually we belong to.

It's that kind of, it gives that kind of belong belongness, I dunno the word. Yeah. Alright, so after that, we obviously, uh, in my timeline right, we have itil, ITIL started, and ITIL the latest version of itil, which is ITIL four.

Okay? Um, and, and it came back in 2018, you know, and ITIL is a framework as many of us know, okay? It's the most widely used best practice framework for IT service management and service management in general.

And it provides organizations with a comprehensive guidance, uh, about how to manage their services in this digital economy based on the fact that, you know, there is no services, I would say, uh, nowadays that are not IT enabled. So we need to think about, you know, the profile, it's profile over the last 50, 60 years. And actually the next slide, and I'm not gonna go into that in detail, but it actually gives a bit of an idea as to how it evolved.

Because it has evolved since the 1980s when it started with version one, you know, and we were talking about components and technical and, you know, the infrastructure library and version one and two, and so on and so forth. And then we went to version three where we even dropped the IT part of IT service management to actually open it to all kind of services and so on. And then we are gonna come back.

When we come back at the end, which is where we are gonna do the comparison, we're gonna be mainly talking about active four, okay? And how it relates to all the other kind of topics and, and best practices that we're gonna cover. Okay?

So, as I said, we'll come back to it, right? The next thing on our timeline, and this is, as you can see, the color here is te So, so, so there are different colors, as I said. I just wanna iterate that.

Alright? So it is a, sorry. Agile is a group of methodologies that demonstrate a commitment to tight feedback cycles and continuous improvement.

Okay? Agile has been so successful, but, uh, initially I think people misunderstood. They, they, they thought Agile was a hype, okay?

And everybody jumped on Agile. Whether whatever they were doing was actually working, would would suit an Agile approach or not. Uh, agile is really mainly about experimentation, okay?

So, um, it gave us initially the Agile manifesto, okay? Where we say, you know, as agile people, we value individuals and interactions over processes and tools. We value working software over comprehensive documentation.

We value customer collaboration over contract negotiation and responding to change over following a plan. So it's all about flexibility and it's very, very much, uh, consumer, uh, driven kind of thing, which it initially wasn't actually, it also gave us the, some agile concepts such as experimentation. It's, it's, if it's something we've never done before, agile would be the perfect way to do it, because it gives us the option, because it's time Bobs and it's very, it has very short feedback loops and stuff like that, which we're gonna be covering, you know, because of all this, it allows us to try something and if it doesn't work, then we cannot try something different in the next, uh, sprint kind of.

So it give us experimentation. It give us what's, you know, sprints and scrum methods, you know, and increments. And it's all about speed and time boxing.

It gave us the concept of servant leadership. You know, it gave us the concept of, you know, some events and some ceremonies within the, within Agile, like sprint planning, like daily standups, like sprint reviews, retrospectives, you know, it gave us ideas and concepts like teams, velocity, velocity or capacity, you know, customer centricity, as I said, you know, short feedback loops, responsiveness, flexibility, and so on. It also gave us, you know, ideas and concepts of product backlog, you know, epic and user stories, minimum viable products, the definition of done, which is something that is so important and a lot of organizations and a lot of people, they don't actually get this, right?

You know, it's very important. Obviously it gave us new ideas of actually how we can size and I come from an application kind of background. So, you know, we used to use function point counting and all that kind of stuff because it's very, you know, um, legacy applications, large applications, but obviously with an agile approach, you have different ways of, of sizing, like using t-shirt sizing, you know, story points, et cetera.

But it also gave us ideas like, you know, burn down and burn up charts, obviously burn down to actually determine and project whether you're gonna finish on time or not, and do something about it being proactive. It gave us the agile principles, you know, like a priority. Look at the priority, okay?

Our priority to satisfy customers through early and continuous delivery of valuable software. I'm not gonna go through all of them, okay? But early and continuous delivery, you know, um, of valuable software, it's all about working software, okay?

Um, building project that are motivated people. So we come back to this idea about, you know, motivating people, which makes the, the human, uh, uh, the human side of, of, of, of work very important. You know, if they are not motivated, they are not gonna actually go over and beyond, okay?

Um, face-to-face conversations. So it's all about also collaboration, okay? Um, about, you know, sustainable development.

Everybody's working and delivering to the same pace all the time, you know, um, simplicity, which is again, we come back to that simplicity thing, which is very, very important that, that lean has actually brought in, you know? Uh, and, and so on. Alright, so the next, um, the next kind of topic we are gonna be covering is DevOps.

Okay? Uh, so DevOps is a cultural and operational model that fosters collaboration to enable high performing it to achieve business goals. DevOps actually is a branch of Agile, okay?

So it is based on the agile principles, but it is all about bringing, actually, let me go here. So DevOp is all about bridging the gap and actually, you know, giving us a, a solution, you know, to the issue of the world of confusion and to the world that used to be bit between deaf, them, ops us. So it do, we, we always had, I mean, I, and I told you, I work in software culture assurance.

I used to go and do some audits and appraisals and assess and assessments, and people in operations would say to me, you know, we came this morning and there is a brand new thing that we have to support, and we don't even know what it is, right? Well, that used to be the case, right? So DevOps actually making sure you know, that bringing the DevOps and the reason they've done it, as a lot of you may be aware, is because we used to queue quite a lot, you know, to waiting for other teams to do things, you know, that we needed in to deliver the kind of, uh, business as usual or whatever projects we were, we were working on.

So now the whole idea here is making sure we bring all the skills that we need to look after the end-to-end. We have an end-to-end responsibility for the whole service or the whole product. And within the DevOps team, we're gonna have all the kind of skills required to be able to actually take care of the whole thing.

So it gave us this kind of, um, you know, uh, uh, solution for this kind of issue. It also gave us another solution for organizational silos, which are nightmare for organizations, really, if the silo ends up being opac, then obviously every silo within the organ and silo can be like business units as you know, all that, or divisions or departments. But the thing is, when we have, you know, black box, um, silos within an organization, we end up with, you know, organizations within organizations, we end up with hidden agenda.

We end up with, um, you know, inability to, to know what's going on or to make organizational decisions because we don't know what's happening inside of each silo. Plus every, every one of those silos end up actually competing with the other side, rather than we all working together and understanding we're all supposed to be part of the same system. We are all little jigsaw puzzle pieces in the big jigsaw picture.

You know, we compliment each other and we have to fit exactly in the spot, but we need to understand where we supposed to fit in context of the big picture. Okay? So it's all about, you know, uh, it gave us a res, a, a, a solution and a resolution to this issue, you know, of DevOps.

So now we have everybody within the same team, and in order to do that, we're gonna see, we need to be multi-skilled, you know? So it give us also, um, some principles, you know, like customer-centric. So again, DevOps, as we said, it is a branch of agile.

It is customer centric as well, you know, creating with the end in mind. So understanding the big picture and then, you know, we need to understand what we wanna achieve in the, in the long term kind of thing. You know, end to end responsibility for the whole service or product, you know, cross-functional, uh, autonomous teams.

Again, building on agile, again, self-managed team, autonomous teams, you know, continuous improvement as well as automating everything we can. One of the huge strengths of DevOps is automation. Everything we do in DevOps is actually automation is automated, um, beyond the coding, okay?

And that's what what makes DevOps very, very strong and very successful as well. It also gave us quite a lot of, um, benefits. You know, think about cultural change, you know, uh, transparency, collaboration.

So it brought you see, the point is DevOps is the solution to the silo thing, because in a DevOps organization or you know, based organization, you have to cut across all. So you collaborate across all your, uh, silos. So the silos, you know, sometimes you, you have to get structured in a silo format or in that kind of format, as long as they are transparent and people know what's going on, and we are able to work together and collaborate across, that's okay.

It's when the silos become black boxes, you know, when they become really opac, this is when it, it gets really hard and, and it gets very, um, very bad actually for the organization, you know? Um, but in a DevOps environment, we have collaboration, we have employees engagement. There is no bureaucracy, uh, this trust this and, and, and the trust and the, the fact that we don't, we don't fear to ask question will lead us to innovate, you know?

Um, this is very, very important. Risk taking is very, very important too. And it comes with the, with the cultural change kind of, uh, approach.

Okay? And we also mentioned, you know, the, the multi-skilling, you know, and this takes us to the, uh, the DevOps profiles, you know, skills profiles, the tea and the pie, and the calm kind of approach. Um, which is actually making sure people are multi-skilled within the DevOps team.

Because we, we cannot have teams made of 60, 70 people. You know, we need to make sure people within a smaller kind of size team are able to do multiple things to support each other, and to be able to support the end-to-end product and service. Uh, it gave us other thing, obviously it gave us, um, speed because everything is automated, which led to cost reduction, you know?

Um, and, and the use of common tools will, was a, a again, use of common co, uh, co common tools instead of having everything using their own tool. Well, that made things a lot easier and faster and, and so on. Uh, it gave us improved quality.

So we have less failure, you know, um, we have short feedback loops. In other words, we're shifting left, you know, um, we put fail safe. Um, remember that Fail safe, where it's coming from.

Well, obviously DevOps is also based on lean as, as we said, which means also Agile is based on lean. Um, it, it also led to improve decision making because we have more visibility into what's going on, okay? Uh, and measurements and all that.

It give more stability and obviously customer satisfaction. Um, DevOps also gave us the three ways, you know, uh, the first way being related to flow, you know, um, which is system thinking flow. So it's all about going left to right.

And then the second wave is about, you know, uh, amplifying the feedback loop, which is actually right to left. And then the third wave being, you know, culture of continual experimentation and learning, which is something that, um, again, uh, we we're gonna look at, but it is actually using that as well. It also gave us, you know, it also uses value stream management.

Okay? And finally, we get to the last topic here, which is SRE, which is site reliability engineering, which is an, an, um, a discipline that uses, um, software engineering kind of, um, practices and applied them to is to infrastructure and, um, operational problems to solving, uh, infrastructure and operational problem. The SSRE or Saturn Liability engineering is a special case of the OPS implementation, you know, and it offers principles and practices that will enable organization achieve the appropriate and appropriate, cannot emphasize enough the importance of the term appropriate levels of reliability, um, sustainably within the organization in order to, to handle.

Also, it helps also organizations handle problems in massively distributed environments that are operating in mind-blowing scales. So there are certain, so SREs is not the silver bullet that is, that we could use for everything. It's mainly for organizations that, that, that operate in a diversified, uh, kind of, or distributed environment.

And, um, that have, you know, that growing at the very, uh, very large scale. Um, so obviously it's all about, you know, measuring reliability, availability closely. And when it comes to measuring, we're talking about SLIs, SLOs, SLAs, you know, but then if we're talking about SLOs, we have to talk about error budgets, which are the rate where your SLOs can go wrong, uh, uh, uh, and then, you know, um, and then if you are gonna, if you're about to breach us and you, you error budget and your SLO, then you need to have some policies in place, which brings the concept of error budget policies, you know, and then it's, again, it's about embracing risk, okay?

With SRE brings a monitoring and observability. Um, it also talks about anti-fragility. It's, it brings culture of culture of change, you know, obviously, um, or, or the, the, the culture of the organization needs to change because we need to accept that failure is normal thing, okay?

Which is not something that people in it are used to. Okay? Um, so again, it's important to understand, you know, the culture of, um, uh, in some organization we used to have, uh, blame culture, you know, and stuff like that.

That's not gonna work. You know, it's not gonna work in an agile environment. It's not gonna work in the DevOps, it's not gonna work here.

It never worked in lean, but we still have it organizations that are, you know, where, where, um, the blame culture is, is very prominent. And when that happens, the sphere, and obviously people do not take risks, uh, they don't innovate. They just do the minimum, you know, tick the box so that they can, you know, the less you do, the less mistakes you make, you know, that kind of stuff.

It also, and I, I, I, I, you know, I, I put these in clusters that are more related to each other, you know, so it brought like, um, um, it's, it's all about common sets of tools between people working in development and people working in, uh, doing SRE and in operations, it's all about, um, reducing toil. Toil is all these operational activities that we have to perform, um, that are actually, um, that can be automated. So if it can, it can, if it can be automated, then we shouldn't really manually do them manually.

It's, it's not, right. It talks about the wisdom of production where, you know, you bring your, um, expertise that you have built because you work in production, you know how your systems are gonna interact with each other. You know, people working in, in only dev kind of environment don't necessarily know what happens when it goes into the live environment, when whatever system or whatever service, uh, they are developing goes into the live environment.

Whereas people in operations, they will bring that wisdom of production into, um, depth. So the point of SRE is making sure that we don't end up with people, that people that are specialized in development, people in SRE, we actually are, uh, having a common set of skills so that people work 50% of their time on development, 50% of their time on SRE and operations activities, right? Uh, and then not only that, that SRE team was including development and SRE people, at the same time, you know, they will be also spending, everyone will be spending 25% of their time on call.

You know, so like at least one, one week a month being on call. So everyone is experiencing, um, the same kind of, uh, having the same kind of experiences. So we end up actually bringing that wisdom of production tool, the development side of things.

Um, it also talks about, uh, uh, standardization. Uh, think about, you know, everything that is done in SRE, uh, in order to make sure we have reliable and available, um, uh, environments and systems, we need to, um, we need to do everything as a service. So we need to standardize everything infrastructure.

So all these operational activities that we are supposed to be doing in operations, we do them, you know, uh, as a service. So infrastructure as a service is actually coming, you know, that's the concept that that SRE is using by, by all means configuration as a service. Because the whole point here, we're trying to make sure that our environments are identical.

'cause despite all our best efforts, you can have the best development, the best, uh, testing environment. If production environment is not identical, then every time you are actually bringing a new feature into, uh, the production environment, there is always this, um, risk in that it's gonna go out. And the whole point also of SRE is making, keeping a balance between, you know, having new features released into the live environment and maintaining the reliability of your live environment, okay?

So they actually bring also, um, the concept of, um, um, reducing the cost of failure. And one, one of the ways to reduce the cost of failure is, uh, by actually making your releases much, much, much, much smaller. So they talk about canary releases, they talk about simplicity, you know, um, and it's all also about making reliability a first class citizen.

So reliability, people working in SRE or SRE within an organization will have a say, just like people you know, in development, okay? So reliability has the same kind of importance, and the organization is paying the same attention to reliability of the service as they are to launching new, uh, functionality and, and so on, features and so on and so forth. So, anyway, reducing, as I said, toil in the past, and it has a lot of kind of practices and principles, which, some of which we're gonna bring and show how actually ITIL is actually interacting with that.

So now we're gonna be talking about the bit that this presentation is about, which is how is then it relating to all these other topics, okay? We had to go through what we've gone through in order to be able to do this, right? So, um, what ITT four gave us actually is the service value system.

It gave us the service value chain. It also gave us the practices, the 34, the 34 practices, which when you add those practices to the activities of the service value chain, you end up building what it refers to. Uh, you know, the, the IT flavor of the value streams, which is, you know, putting prac, the activities from the service value chain activity at the top there, you know, taking one of those OT pie activities, you know, um, and then identifying the practices that support those activities and building your value streams, your IT value stream, okay?

It also gave us something, uh, very important, which is the four dimensions of service management, which are the different types of resources that the organization has to use. It's everything, all the resources the organization has will be actually placed in one of those four areas, you know, organization and people resources or information and technology resources or partners and suppliers related resources or value streams and processes. Okay?

So obviously it's very important to always consider all those resources in whenever we do. The other thing that IT four gives us, which is really, really strong, is the guiding principles. Yes.

And those are my favorite. So the guiding principles are actually, um, those principles that will change and IT organizations' culture. If we start looking at those principles and implementing them correctly, then um, we are gonna change the world.

If you, you know, so, and this is actually the guiding principle is how IT four is actually aligning to all in the other, um, topics and disciplines and best practices that we talked about so far, okay? Because it's not about whether we should use it or something else. So the point here is, it is actually now, now saying it's, you don't have to make a choice whether you use ITIL or, or whether you wanna implement it or lean or ITIL or DevOps or ITIL or, you know, agile is actually, it is taking, you know, has looked at all these other, um, best practices and brought all the best of everywhere and built it into it.

Four, thanks to the guiding principles. So we talk about focus on value, and we're gonna be looking at how is focused on value in IT. Four, you know, mapping to all the others.

And then we're gonna be looking at each one of those. That's how we're doing the mapping, and that's how we are actually showing the alignment between it, um, four and, you know, the other, um, best practice we just covered. So let's just, let's just have a look now how ITT four aligns to these other, um, uh, yeah, ITT four guiding principle.

The, as I said, the guiding principle is the catalyst, it's the, uh, the channel through which IT four is actually bringing those ideas into here. And what I have been doing, uh, for each one of those kind of slides, so what you see on the top right hand side of the slide is actually the color coding that's actually telling you what this, the, the blue color color is lean, you know, the, uh, the, the three color is agile, you know, the purple color is DevOps and the orange color color is Ari. And I'm actually saying, okay, so the first guiding principle we are talking about in here is focus on value.

And it's such a big one that, you know, it's on in a slight of its own. Alright? So what do we, what, how did ITIL actually align to the lean, you know, to lean from a, how did focus on value aligned to lean?

Well, remember lean, it said unrelenting focus on providing customer value. These are the lean concepts, okay? Providing exactly what's needed at the right time based on the customer demand.

So we just making sure we, we, we don't do more than what we have to do. It's all focus on value, okay? It's all about focus on value as a principle in IT is all about making sure you know who your stakeholder, you, who your service consumer is, who your stakeholders are, ask them what's important to them.

You know, why are they, how are they gonna use your service? And what kind of aspect of good service are important? And make sure you deliver to that, you know, which is focus on value on what is of value to the stakeholders.

Alright? So obviously, you know, lean has talked about, you know, value through the eyes of the customer, because again, the definition of value in 94 is the perceived benefits, usefulness, and importance of something perceived by who. Here we go.

It's value through the eyes of the customer, obviously, you know, it's something we need to always think about. So you see it is it for, is actually bringing us all these good concepts and building them into how we do it. How can we manage our, um, IT enabled services, you know, making sure we are actually leveraging and capitalizing on all these good practices, um, that, that have been there for, for a long time, but we're now bringing them into how we do it again.

Um, uh, lean talked about the, the value add criteria. What makes a step value add, okay? There is no reason why we cannot use the same in, in, in when we are implementing itil, for instance, the lean culture, as I mentioned, you know, keeping things flowing in a value added and effective manner.

Remember when you talked about that earlier, okay? Leading by focusing on the results, where the results, uh, where the customer value is created and building, you know, capabilities in. So all these are coming from, it's showing how focus on value in is actually aligned to, to lean.

And then the next actually, uh, set of, um, uh, bubbles are related to how focus on value is aligning to, uh, agile. Okay? So again, the, the, the manifesto, it says we value, it's all about value, right?

So it's the manifesto, it's about the minimum viable product, it's something of value. How can we make service consumer realize as much value as possible as quickly as possible? We have minimum viable products kind of concept we are bringing into it now, you know, uh, customer driven, uh, approach, you know, continuing at attention to technical excellence and wood designs, you know, flexibility.

All these things are coming from Agile and they're all related to the value part, you know? Um, okay. And then let's have a look at DevOps.

So as far as DevOps is concerned, we talked about customer centric action, well, that's, again, always on value to the customer to us and to other stakeholders, you know, creating with the end in mind, again, it's, it's all about the value, alright? Um, cost reduction, customer satisfaction, you know, uh, and so on. SRE with co focus on value, okay?

So how SRE is actually mapped to the focus on value guiding principle or vice versa, okay? Um, it's all about reducing toil, you know, so anything, this is op, it's also, you know, what, it's optimized and automate, we're gonna talk about it as well in the optimiz and automate, you know, or it's all about understanding, you know, it's the SLOs, you know, making sure we are delivering to what the customer wants, improved availability and reliability, you know, reducing the cost of failure. All these are value related kind of, uh, concepts that are coming from, uh, SRE, which can be very easily mapped to focus on value in itil.

Okay? So if I, this is just showing you, I, I'm not gonna go through it, it just shows the, the consolidated kind of slides that has all the different kind of, um, how it maps to all the different, um, um, best practices and topics that we've covered before. Okay?

Um, yeah. And then we go through the same with the other guiding principles. So this guiding principle is all about start where you are.

And in itil start where you are is all about, you know, uh, assessing where you are first before, you know, rather than starting from scratch every time you wanna implement something, it's all about really knowing what you have in context of what you wanna achieve so that you know, what are the things you're doing well as it stands now, you know, in the current state, which you can expand on or reuse in other areas of the organizations. What are the things you need a little bit of tweaking to perfect and make it apply, uh, you know, uh, applicable and aligned to your desired state, and what are the things that you need to restart? Okay?

And then that's exactly what Lynn told us in GaN Chicken boots, which is go observe for yourself, because actually in itil, they, they don't even recommend, you know, when you go and assess where you are, you need to do it directly and objectively. So you need to go and see where the value is being created and making your own notes rather than just, you know, relying on reports and stuff, and the gemba, which is the same, you know, where the action is, where act, where, where the value is being created. And then if we go to the next, uh, guiding principle, which is progressing its degree with feedback.

This is coming straight from Agile. It's all about understanding the big picture, you know, and then taking a subset of that picture, but progressing, stop refining the requirements and then refining the refined requirements, then refining the refined, refined requirements, because that's what we used to do in Waterfall. And we would go for month and month and nothing has done, we were still in the requirement stage of the project, you know, so obviously that's one of the things that Agile has changed, but it also came from lead.

So in lead, you know, continuous learning and everyday improvement, this is the feedback bit. You know, uh, the, the accept no defect make no effect, pass no defect. Again, it's all about making sure, you know, we get the feedback and we learning from our mistakes and, and we always improve the kaizen, you know, value stream management.

Now, agile is a very important part, you know, this progress iteratively with feedback is also directly related to Agile with Sprint is about the iterative, you know, approach. You know, it's all about the iteration and about the feedback at the end of the sprints. And then, you know, building every sprint will always be better than the sprint before because it takes, you know, the feedback coming from the sprint review and the feedback coming from the retrospective and building that into the, the action, uh, all the, you know, the, the, the following sprint.

So every sprint is always better than the one, uh, coming after. So all these concepts coming from agile, you know, are all related to either the iterative kind of, uh, aspect or the feedback and the learning from your mistakes aspect, which is what this guiding principle is all about. Okay?

If we look at, um, this is coming, the DevOps contribution to, or, or how progress it is with feedback is actually met to DevOps. Okay? Again, DevOps talk one of the principles about continuous improvement, well, that's what feedback and improvement it's all about.

Okay? The second way, which is ab, uh, uh, you know, amplifying the feedback loops and shifting left, you know, um, short feedback loops, you know, and the third way, which is all about experimentation and learning, you know, al experimentation and learning is also part of, you know, how, um, uh, progress iteratively with feedback is actually, uh, aligned and maps with, um, DevOps. And then with SRE, we talk about implementing gradual change, progress, iteratively progress, iterative, gradual change, okay?

Um, the canary deployment, you know, the, the blameless sport mode, postmortems, you know, in, in SRE we talk about, you know, learning from your mistakes, you know, um, again, learning from failure, accepting failure as normal, that kind of stuff. Okay? So again, this is just a slide that actually shows the consolidation of, of what all what we've covered, you know, for this.

Alright? The next guiding a couple of guiding principles actually, uh, we're gonna be covering both collaborate and promote visibility as well as think and more holistically. And these two are so much related to each other.

I mean, collaborate and promote visibility, helps think and work holistically. So, and they both actually, I see them both coming from DevOps related too much very closely from DevOps. So we'll actually see how they relate to all of what we've covered.

So collaborate and promote visibility. Again, there are certain things that are coming from lean, you know, like, um, the Kanban, we talk about visibility today. We say use kandan boards, okay?

Um, uh, which is about making your work visible, knowing exactly what you have to do, what you're doing, where you, you know, what you've completed and so on. The lean culture is all about, you know, the visibility, the collaboration, um, the Toyota production system is all about. It has teamworks in the, you know, at the crux of it, uh, people at the crux of it, okay?

Uh, so it's all about collaboration and so on. Uh, long-term relationships with stakeholders, all these are related to collaborate and promote visibility from lean. And then if we look at the same from Agile, okay, so this is actually talking about, you know, um, the servant leadership.

It's about, again, visibility, the, the, you know, collaboration, you know, the events that happen, the sprint review, the daily standups, you know, it's all about working together. Um, the face-to-face conversations that are part of, it's the, one of the best ways to actually deal. One of the principles of, uh, agile is to actually, uh, if you wanna clarify something, have face-to-face meeting rather than, you know, emails and go back and forth, right?

It's one of the principles, uh, business and business people and developers must work together daily throughout the project. Well, it's, that's collaboration, isn't it? You know, and it's also making sure everyone knows what, what everyone else is doing.

Self-management, manage team trust to get the job done, you know, all these kind of thing. The motivation of people and all, all these are actually will result in better collaboration and visibility as well. Um, again, uh, in here with the DevOps, a lot of the stuff related to DevOps would actually be, uh, you know, it can apply to collaborate and promote visibility as well as think and all holistically, um, collaborator promote visibility in it is all about not working in silos, in black box silos so that you can actually see what's going on, what's the progress of work, you know, what's the flow of working progress, uh, and being able to identify and uncover if there is any waste or, you know, um, if you have any excess capacity and so on and so forth.

So it's actually, you're not cutting across all your, um, all your, uh, silos. What I think and work holistically is all about. It's, it's using collaborate and promote visibility cutting across, but it's asking about making sure we involve all the right stakeholders that we need to involve at the right time, and that we consider all four dimensions in everything that we do, all the resources related to the four dimensions organization and people, information technology, farm partners and suppliers, value streams and processes in everything we do.

So, um, the next couple of, um, um, bubble sets, sets of bubbles are related probably to both. So here, having no fear, so this is actually collaboration. So obviously the collaboration part coming from DevOps is actually relate to collaborate.

Um, but end-to-end responsibility is also about cutting across, but it also as it's, as you can see, relate to think and work holistically, which is all about system thinking. You know, we are all part of the picture on the bo on the top, on the cover of the puzzle box, right? We're all part of it.

We need to understand where we all fit, where our individual contribution fit, but where we, you know, in context of the whole end to end, um, cross-functional. So again, DevOps talks about cross-functional autonomous team if teams, this is about collaborate and promote visibility as well as think and work holistically, you know, establishing that kind of trust re resolution of the issue of the wall of confusion we talked about. Well, that's exactly collaborate and promote visibility as well as think and work holistically.

Um, when the organ, the issue, the, the solution to the issue of silo, again, it addresses both of them. Okay? Breaking down silos is coming specifically from DevOps, you know, because it has cut, um, it broke down silos.

It's all about transparency, employee engagement, all these are things we talked about as concepts or as principles coming from DevOps and, and, and they are, they apply to those guiding principles. And then from an SRE perspective, specifically with think, and well holistically, you know, shared ownership with the developers, you know, um, by sharing common sets of skills and tools and common sets of practices. Well, again, it's, it's all about, again, think and work holistically as well as collaborate and promote visibility.

Shifting left wisdom of production, you see, so it's again, uh, eliminating boundaries between development and SRE and so on. And then obviously, I, I think brings us, you know, also we, we did say, you know, this is not only how, um, this kind of mappings we've done also relate to the service value system itself in it, it's not only related to, uh, the guiding principle, uh, those two guiding principle, it also relates because the fact that we have an SVS, it means that, you know, we're working together as a system, you know, how we need to compliment each other. It's a bit like the human body, you know, you need the arms and they have a function that is different to the function of the legs.

They have a function that as is different to the function of the brain, to the function of the heart. So every team has a different function, but we need to compliment each other to make actually sure the whole system works. Uh, if the brain doesn't work, nothing else is gonna work.

If the heart doesn't work, nothing else is gonna work. So these are like, you know, this is a very well old machine. That's exactly what we need to achieve in our organizations these days, right?

The next couple of guiding principle, we only have like, I think, um, these are the last two actually. Um, so keep it simple and practical. And the next one, which we're gonna be covering would be optimize and automate.

And guess what? These two also are to some extent, related. So keep it simple and practical supports optimize and automate because you have to have simple kind of workflows and processes to be able to, you know, automate and so on.

So the keep it simple and practical, this is coming straight from lead. Keep it simple and practice. It's all about lean right here.

A lot of things here are related to lean, obviously. Okay? Uh, reducing variation in the lean culture, providing exactly what is needed based on customer demand, uh, you know, value add criteria and, and, you know, getting rid of waste.

All this is actually about lead, isn't it? It's keep it simple and practical use, and I think we say keep it simple and practical is about using the minimum number of steps in anything that you do. Anything that does not contribute to value, you need to eliminate it after you make sure it doesn't add value to someone else.

Okay? But that's in a nutshell, that's what it is promoting, which is actually what lean is all about. Okay?

Again, from Agile, from agile, you know, we talk about, you know, the T-shirt is making it so easy to actually go and do sizing because everything is clarified for you. You can, you, you know, the minimum viable product, you know, the simplicity is essential, which is a principle in agile. This is sip, keep it simple and practical.

SRE, again, SRE talks about simplicity, talks about, you know, trying to reduce complexity, reduce and reduce the cost of failure by actually having your, uh, can deployment, very, very small deployment and, and testing that nothing is gonna go wrong when you know that everything is done, you know, for a, at the small level, you can then go and do it at the bigger level. Okay? And then we have optimize and automate.

So from Agile, how agile, uh, uh, uh, aligns and how ITIL aligns to Agile from that perspective. You know, in, uh, in ad in, uh, sorry, in lean, the, this is actually lean. We're talking about improving value across the whole value stream.

Okay? Um, so again, we wanna make sure we are working throughout the whole, um, the whole flow automation with the human touch, because this is talking about the automation as well, keeping things flowing in a value added and effective matter as well. You know, we talked about, you know, in, uh, this is in DevOps, uh, so it's about automate everything you can with the CICD kind approach is all about automation.

You know, um, in SRE we talk about, uh, reducing toil. Absolutely. The way we reduce to and how it's promoted in SRE is through automation, okay?

Uh, automating this year's job away kind of thing. Fixed processes before automation. And this is something that ITIL is actually saying as well.

Make sure, you know, what is more important than automation is the workflow you are gonna use and that you're gonna operationalize by automating it. You need to make sure that that workflow is well designed, is robust, otherwise you're gonna, you know, if you, if you have a crack in your process, automation is gonna, is not gonna solve, it's gonna actually, uh, make it more visible and it's gonna be visible much faster, actually. So this is how, um, actually, um, eil, uh, those two guiding principles in eil, um, relate to all the topics we talked about.

Okay? That's it for, uh, from my perspective. These are my, uh, my details.

Please, if you have any queries, if you need any more information, reach out to me. Uh, contact me on LinkedIn or send me an email, or if you're local, just gimme a call. And, um, yeah, thank you so very much for your time.

I hope you enjoyed this session and all the very best with the rest of the day. All the best. Thank you so much.