I’ve been working with ITILⓇ since the early 1990’s when I was first introduced to it at F.I. Group and worked my way through the Foundation certificates, ITILv2 Manager’s Certificate, ITILv3 Expert and recently ITIL4 Managing Professional certificate.
Then, once I became a self-employed consultant, the breadth of my knowledge grew, as I started to absorb other ways of doing things. About 12 years ago I started to play with COBIT, through 4.1, 5 and now 2019. Then I started to speak with people who used Lean Six Sigma and learnt a bit about what they do and how they think and work. I can’t say it made a huge impact on me, but I was aware.
In 2016 I was encouraged to get interested in DevOps and flew to San Francisco for the DevOps Enterprise Summit conference. That was interesting for a few reasons. Firstly, I’d never been surrounded by so many developers before. I also realised that just because they used Ops in the title, it did not mean that they would talk about Ops, although admittedly there were two out of many which did. Those speakers were Mark Imbriaco and Erica Morrison. The conference was also during the 2016 presidential election results, so as you may imagine, that in itself was interesting.
Through DevOps I started to look at agile ways of working, Lean IT and Kanban.
Due to my interest in all these things and my own inability to remember as much nowadays, I have to keep refreshing myself about all the different versions, frameworks, ways of thinking etc. and that’s because there is so much to learn. If you want to work in a modern organisation, it is expected that you will be across or aware of most of these approaches. You may not need them all, all of the time, and in some roles, you may not need some of them at all, but most modern organisations who have been through some level of digitisation will be using or talking about those approaches.
It’s this interest in all the different ways of thinking and working which has made me realise that we’ve now reached a point where all frameworks or approaches seem to have a set of principles behind them, whether it is the so called dinosaurs of ITIL & COBIT, or the cool kids at the party, DevOps, Lean etc. Agile tries to convince people that it’s cool, but it’s nearly as old as ITIL and Kanban is older than all of them!
So principles. What are they? Why do we care about them? Why do we need them? What are all of these principles?
ITIL4, released in 2019, introduced the 7 guiding principles, down from 9 in the Practitioner book.
These principles are :
Then we have COBIT 2019.
They are very formal but clear: deliver value, think end to end & focus on a dynamic governance system as well as management. This is pleasingly what you expect from COBIT.
Now agile, which has its roots in the early 1990s with approaches like RAD in 1991, Unified Process & DSDM in 1994 as well as Scrum from 1995 is probably best known for it use mostly in the development world, but there’s plenty of other uses and flavours out there, with agile project management, agile managing & agile parenting courtesy of Rob England and Dr Cherry Vu at Teal Unicorn, and many other varieties of agility in the workplace.
You can see their principles here:
Fundamentally, it's about satisfied customers, welcoming change, working together, delivering frequently at a constant pace, talking to others, being motivated, self organising and adjust when you need to.
Then we have Kanban which came about in the 1940’s or 50s at Toyota in Japan, with the intention of reducing stockpiles of material and to limit production to demand.
The 5 key principles of Kanban which have now been arrived at are:
The principles of DevOps are lovingly referred to as CALMS or CLAMS if you prefer kaimoana.
CALMS for those of you who may not be aware stands for
Getting the culture right is hard. Most people reading this are probably working and breathing within the IT Operations sphere of an IT department. Or connected to it.
IT Ops people, generally don’t like change. We are designed to keep things steady; keep the lights on. It’s what we have learned over 5, 10, 20 years of Ops work. If things are changing, it’s the Operations person who gets the call at 2am and has to fix the server, network or whatever is broken.
Ops are risk averse. So you need to create an environment where they feel safe and can experiment.
It’s all about creating a safe environment where they can not be blamed. Too many CIOs still blame IT Ops as a team or individuals when something fails. If that happens, then you are never going to get people who want to try new things or better ways of doing things.
Start at the top.
So many DevOps conferences, presentations, articles etc talk about tools. If you are an IT Operations team keen to use the DevOps principles to improve the way you are working, it doesn’t need to be a massive spending spree.
Monitor everything that you can. There are some great free tools and some great cheap tools which will help you get started. Hard to believe maybe, but there are organisations out there who don’t monitor servers - capacity or availability, networks, applications. Learn what is happening. Alert when it is sensible to alert. Keep fine tuning. If you don’t know what is happening, you can’t improve it.
As you learn what needs to be done, to fix issues, look into what can be done to stop those issues. Most tools allow you to script auto-actions before alerting, so look into that.
Do you have to perform the same task day in day out? Try and script it. If you can’t do it, get a contractor in for a few weeks to do it. Work out what you need doing and get the contractor to script it for you. A few days of a contractor will save you weeks or months of work redoing tasks or reacting to alerts.
Lean is all about
Note, this perfection is primarily to ensure that in your workstream you don’t pass errors to others in the flow. That creates rework and is waste.
Lean is all about reducing waste. Don’t do the stuff that doesn’t need doing.
So if we imagine a new member of staff is being on-boarded. The new person will be adding value to the organisation (identify value). The Value Stream will list all the teams involved in onboarding, their tasks and how much effort they need to put in. The flow of work is understood.
Now let’s imagine that HR makes a simple spelling mistake in the individual’s last name - got the i and e the wrong way round - which is easily done when humans are involved.
The new starter goes to get their id badge, but the name is spelt wrong. No biggie, but the badge needs to be redone. Then they sit down and their AD account is wrong because IT had the wrong spelling. Again, no biggie but that and their email address need to be changed. Then payroll ask the person to fill in an online form. Guess what..they have the wrong spelling, so the bank won’t recognise the person. More rework. None of it may be big, but it all adds up.
So just like most things in IT, baseline where you are. If you think you can speed up the time it takes to provision a new starter, understand how long it takes now. How often does the requester come back with “Very nice, but it doesn’t have this installed” or “We requested a new user be set up with a laptop, but they don’t have the right software or access to the right groups in AD”. Measure this as a baseline and then try to improve it. What are the new measurements? Have things improved - whether time to deploy or perceived satisfaction?
Then you will know whether you are improving. If you aren’t why not? Can you improve on it further? Should you undo what you have done and try something else?
Another key tenet of DevOps is the sharing of knowledge, information and capabilities.
Share knowledge of systems with colleagues, to reduce the risk to the business if you aren’t there. Give yourself a break from being called during the night or holidays. Heroes are not the ones who get woken up at 2 am to fix an issue that nobody else knows about. Heroes are the ones who share knowledge and skills so that they DON’T get called up on holiday. Start to embed that in the culture.
Share capabilities with others. Fed up of getting calls for simple tasks? Show the Service Desk how to do it. If they don’t have permissions, script it so they don’t need the permissions.
So for example, Change Management people could share what they are looking for in a Change, so that everyone knows what is needed before the change is reviewed.
Sys. admins could provide developers or projects with their non-functional requirements at the start of a piece of work, so it doesn’t have to be rejected at time for support.
If you can give others further left in the flow (remember that?) the information they need to give you what you need, then does it need to go to CAB? Could it just be a tick box and implemented?
There’s a multitude of areas where knowledge, skills, capabilities, requirements etc can be shared with others to enable value and to deliver that value to the wider business. The more that is kept in silos or individual heads, the slower everything becomes.
You won’t lose your job if you share knowledge. You might, if you don’t. If you can share everything you know and do, the chances are you will get more opportunities in exciting areas.
So, we have all these approaches and ways or working, but I think we can extract the following 6 key shared principles to help us on a day to day basis
So there are many different frameworks, approaches and ways of working out there which help us work smarter.
And I’m not suggesting that you shouldn't learn them. If there is value to you or your job in learning them, get out there, read books, do courses, become certified. But do you NEED to?
I think there are only 6 key things you need to remember, to be able to work effectively and efficiently in most roles.
ITIL™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.