When talking about the “big” frameworks like ITIL, Management 3.0 or Scrum with people from smaller or medium sized companies, you very often hear statements like “That’s far too big for us” or “We are too small to implement this”, or “We don’t do software development”. Somehow understandable, but wrong!
Frameworks like ITIL or Management 3.0 and, to some extend, Scrum are not bibles you have to follow literally. If taken as what they are – a collection of best practises – and implemented accordingly, everyone and every company can make use of them.
Frameworks are not written in stone
I have been using ITIL ideas for nearly 20 years, so let’s start with some thoughts on this. ITIL has developed over the decades from basically a collection of IT operations processes to a more or less holistic approach which can be used for IT as well as any other service management business. The focus is on the value chain, with the practices that made up most of V3 now being the “operational” core of V4. I personally like the guiding principles of V4, because they apply to mostly everything in your daily life and are the link to the Agile world.
I made the experience that ITIL is full of ideas that you can easily apply to your environment without changing that much of what you are used to – as I wrote, it is a best practices framework, and when I started to dive deeper into it – V2 at that time – I found that we already had many ITIL-like processes and functions in place without knowing it. To be “ITIL compliant” we generally only needed to do some amendment and harmonisation work, and the main task was to write down all the rules that we were already following, so that everyone knew about them.
Implement the idea, not the wording
A nice example for how you can implement an ITIL practise is the Change Management Practise (formerly Process). In the ideal world of ITSM, you would have all your infrastructure components as CIs (Configuration Items) in your CMDB and the organisation would provide a CAB (Change Advisory Board), an ECAB (Emergency CAB) and a nice little guide to classify every change you could think of as either Standard or Normal. Every change would then be thrown into the ITSM suite and be dealt with, probably down to an automated deployment. But, and this is where this post’s introduction comes in, in the real world this usually is only the case for really big companies. The average small to medium sized company won’t have this.
But it will have a list of their servers. And their network devices. And all the other IT stuff. Maybe in Excel, maybe on SharePoint or Confluence. So, why not use this list as starting point? (See above: Start where you are!) Just create a list for the changes, which basically only holds a description of the change and the affected item. For planned changes like patch installations, configuration updates or GPO changes, these can then be discussed with other colleagues (there you have your CAB), and they are documented in case afterwards something somewhere else is broken due to an unrecognised dependency. The some goes for unplanned changes, only that you might not have had the time to ask someone for his opinion (ECAB) – but it is still documented and visible to everyone. And if you then introduce a regularly used time window for all planned changes, like in the evening of every second Thursday of the month, and communicate this in the intranet (or an IT newsletter or a sticky note on the IT door), you have a simple yet ITIL compliant change process in place.
One important fact is: You don’t need a full-blown ITSM suite to support this. In the beginning we only had a simple yet powerful self-built ticketing application on the Remedy ARS platform, which we were continuously extending and improving. All other tools like Confluence (for all kinds of documentation), SharePoint (for everything list-based, including a service-based change log and an international IT service catalogue), a federated server database etc. were added over time.
Learn from others, share your knowledge
The key to successfully, continuously improving our IT services and service management was to visit ITSM conferences and user groups, see what the big players were doing, understand the ideas behind the features, and then finally apply the ideas to our application and organisation on a scale that fitted our size. This principle grew to be my guiding principle not only for the ticket application, but for the whole of my professional career.
The ITSM suite: Nice, but not for everyone
Yes, no doubt about that: It is nice to have a central ITSM suite with a CMDB holding all you assets and CIs. But the problem is that the efforts for especially implementing, but also running such a system, do not scale with the size of your infrastructure. Although even the market leaders come with a lot of templates, there is still quite an amount of manual work to be done before the first CI finds its way into the CMDB. I am not talking about licensing costs – these scale properly with the number of certain CIs like servers, depending on the licensing model. I am talking about the configuration work like defining CI classes, deciding on the target level of granularity, preparing your internal firewalls and network configurations to allow automatic discovery runs, probably deploy discovery agents to your servers, get the team trained, and so on.
A product can be anything – also a piece of Software
Many IT people think that Scrum is only for software development. To be honest, I was no exception to that. The reason was that I was mislead by the idea that every sprint needs to deliver a working product. I assumed that a “working product” must be a piece of hard- or software that could be handed over to the product owner to go to the market. What I didn’t have in mind is that also a blueprint can be regarded as a product. The product owner would then receive a new, more improved and mature version of the blueprint after each sprint. After having reached a certain grade of maturity, it can than be used to create a “real” product. By looking at it this way, even complex IT infrastructure projects can be run as agile projects following Scrum principles.
If you are still sceptical about this: Just think of your last waterfallish run infrastructure project: was it really ever fully completed? Or did you do some improvements and reworks after go-live? In fact you will find that you just defined it as completed at a certain level of maturity – see what I mean?
You will have used Agile already without knowing
When I took a closer look at Agile ideas, I found out that I was already applying a lot of Agile ideas to my daily work – just intuitively, often as a result of trial and error. And this is what all the best practices frameworks are built on. One example should demonstrate this:
Imagine a department responsible for providing the collaboration and communications services in a medium sized company. There would be the “classic” MS infrastructure – Exchange, SharePoint, Skype for Business – along with the mail gateways, a PBX, video conferencing and mobile device management. As long as everything runs on premises, your team would consist of one expert for each of the MS tools, plus one for the communications stuff. As the video conferencing systems are highly integrated with SfB, the SfB expert deals with them. All other systems have only very few interfaces. So the team setup would be “I-shaped”: some four people, with external partners supporting in case of one of the experts being on holiday or sick leave.
Now imagine going online, i.e. O365. SfB is a dead end street, so you would add Teams. For security reasons, you want to keep your mail gateways and the option to have some content still on premises. Solution: Hybrid approach. Fine, one additional product, but the others still there – but wait! Teams creates SharePoint sites and mail distribution groups? SharePoint creates mailboxes? Yammer replaces SharePoint discussion boards? A security setting aimed for SharePoint blocks something in Exchange? Okay, now we haven’t got separate products any more, but highly integrated ones, with features being moved constantly being moved back and forth between them.
Solution: The whole team attends an O365 training to create a “T-shaped” set of skills. You still have the expert knowledge for each of the core products, but everyone also knows about the dependencies and features of the whole O365 suite. And where does this “T-shaped” thing come from? Right, from Agile.
Conclusion
If you are working in IT and are somehow responsible for people, services or some other entity, you should ask your boss to book a foundation course for you – and even better, take your boss with you! The foundation classes are absolutely sufficient to get the idea of ITIL or Management 3.0. The same goes for Scrum, PSM I (Professional Scrum Master) gives you the full picture of the basic ideas behind Scrum.
And: Never forget that another important thing is networking. Be it conferences, user groups, discussion forums on social media, or whatever source: Active information exchange is never a one-way street! Sharing your knowledge, keeping your eyes open, getting the idea behind how others are doing things, and applying these ideas to your environment will benefit everyone.
Further reading
- ITIL (Axelos): https://www.axelos.com/best-practice-solutions/itil
- Scrum: https://www.scrum.org/
- Management 3.0: https://management30.com/
