SOLVED: 5 Simple Points To Understand DevOps, ITIL, Agile, & ITSM

Have you ever wondered how Microsoft, Apple, Google, Amazon and others started developing new products/services at an almost exponential rate starting in the 2010’s?  Well wonder no more .  These companies all adopted new operating and development frameworks that has given them dramatic results:

Image Source: Microsoft

Before ITIL (Information Technology Infrastructure Library), DevOps (Developers + Operations) and the other frameworks, products, software and services were mostly developed using what was termed “Waterfall”.  Waterfall provides a rigid development process using specialists to focus on their area of expertise and then hand off their ‘bit’ to the next group and that did produce so efficient outcomes.

For instance, to develop a piece of software or provide backup services, Waterfall would have you:

1. Talk to the client to determine their needs and create a list of deliverables
2. Have the designers, then coders, then the Quality Assurance team, then security staff, then documentation staff each work on the project one after the other
3. Present the finished product to the client for acceptance testing

The questions are, were those outcomes the very best for the client and can the developer easily reuse (and scale up) that work?

The problems with waterfall are:

1. The clients needs or desires may will change as the product is being developed
2. If your work misses some important function, has bugs, or does not meet security requirements you won’t know about it until you are further down the path and that means fixes will be both difficult to and expensive
3. There is substantial delays between each step in the development process
4. Most of the work is custom so there is no ready way to automate and allow the next project to build on the strength of the previous projects.  For example if you build automated testing platform for your first client, you can likely tweak it for the second client

ITIL, ITSM, Agile, and DevOps were all developed as a response to these limitations and state that change to the original plan must not only be constant, but embraced.  They are all about continuous communication and continuous deployment.

If you think of this in food service terms,  your IT shop should be pizza restaurant and NOT the pizza.  In other words, you want the customer and your staff to talk constantly and make changes to the ingredients so the pizza product can get better and better.

---

ITIL, ITSM, Agile, & DevOps Core Concepts:

1 – Eliminate Siloed Teams

DevOps calls this “Continuous Collaboration” and it is absolutely fundamental.  ITIL states:

“Co-creation is as business strategy focusing on customer experience and interactive relationships. Co-creation allows and encourages a more active involvement from the customer to create a value rich experience” SOURCE

Research has shown, and real world experience has proven, that project output is much improved if a multidisciplinary team is formed to iteratively work on a project.  This means that coders, security experts, database staff, marketing people and yes even the customer should be constantly discussing the product as a group.

Those people are to regularly interact so that they each:

1. Learn about the other team members specialized concerns
2. Teach others about their specialty and their concerns on this project

In one of the classes I took the DevOps instructor said the idea is to allow specialists to specialize but to make everyone a generalist too.

2 – Small, Frequent Deliverables

Instead of having a single large final product at the end of your process, ITIL, ITSM, Agile, & DevOps all say you should take break it into as many small products as you can.  Each of those products should be subjected to criticism and testing by all of the others in the team as soon as the code ‘in written.

Continuous integration will lead to continuous feedback which leads to continuous improvement.

On key term you need to know is “Shift Left Testing” which is the notion that testing should be done early and frequently (i.e. to the left side of a timeline) and not just at the end (i.e. the right side of a timeline) when a product is about to be delivered to a client.

For instance, if you are developing a backup management system, the group that handles the firewall changes should make those changes and get them into production as soon as possible so that the software coders, script writers and security staff can actually use those changes.  Waiting until the full system is delivered is asking for mistakes and security problems to plague the final product.

3 – Its All About “Value”

While, both DevOps and ITIL are big on the term “value”, all of these frameworks want you to focus on how the client is improved by a product.

Value does not relate to the price of the software or service you are providing.  Value relates to the overall utility or usefulness to the client.

It is not enough to deliver what the client asked for.  You need to use your skills, experience and process to make enhance your customer as much as possible (and if you don’t your competitor will!)

4 – Automation Is A Required Investment

DevOps in particular wants you to spend to the time and money upfront to develop as many reusable processes as possible.  For instance, if you are developing an end to end security system for a client you may be able to write scripts or buy software that:

1. runs, verifies and reports the backups
2. performs penetration testing from outside the company
3. scans all of the desktops for both malware (i.e. AV) and unexpected behaviors (i.e. SentinelOne/CrowdStrike/Carbon Black…)

After you have these processes in place for one client, you can keep advancing their functions and features for all of your clients… including new ones.

5 – Continuous Improvement

You are never truly “done” when you use these frameworks.  There is no “final product” or finished deliverable.

In addition to constant engagement and constant improvement throughout your development cycles, ITIL, Agile, ITSM and DevOps all require you to keep improving the product or service after the “final product” has already been rolled in production.

Microsoft says their DevOps process has eliminated all of the old KPI’s (Key Performance Indicators), like how many bugs were found, how many lines of code were write or how long something took to be developed.  They now focus their metrics exclusively on the IMPACT of their work so they measure satisfaction, time to fix bugs and how difficult is it to learn.

One of the curious things I have learned from taking ITIL and DevOps training specifically, is that they say doing things in advance is a mistake.  The only reason to do work in advance of the schedule is because there is a roadblock on an earlier task that you should be completing.  These frameworks say it is better to solve the roadblock (which will also help eliminate/diminish that roadblock on future projects) than it is to risk “getting ahead” by guessing that a feature you think you will need in an upcoming cycle… because you could be wrong.

---

DevOps, ITIL, Agile, & ITSM Summary

Initially these DevOps and ITIL frameworks create more work but they very quickly pay off.  The problem is most managers and companies don’t get the culture right and more than 80 of these efforts fail.

Remember that DevOps and ITIL 4 are not monolithic.  The steps that work in one organization will not work in another.  Be flexible when trying to implement their suggestions.

The guiding principles of all these frameworks is to maintain feedback loops of constant communication with constant small product releases which will allow you to fail early, fail often to keep your company and its products improving.

---