DevOps

DevOps - 5 Ideals

If you say "DevOps", people will understand "Kubernetes", "Ansible" or "Cloud", most likely. But, the true nature of DevOps is a cultural change, based on 5 major ideals. Let's dig into these and explain, how they can change your way of working, more than JIRA or Scrum ever did.

Daniel Schier

Feb 8, 2023 — 7 min read

Photo by Andrea Riezzo / Unsplash

Pre-face

In the past, I wrote a couple of DevOps articles already. These are explaining other cultural aspects, like working patterns and modes. Yes, my blog is containing different articles about Ansible, Linux and what-not, but these are only tools.

DevOps is more about the combination of tools, processes, and people with the goal to create a good working environment, often known as DevOps culture.

The principles of DevOps can be applied to almost all companies, even if they don't have any IT in place. I am typically using an imaginary tomato processing company as my reference example.

The 5 ideals

The 5 ideals are one of the corner stones in the book "The Phoenix Project" a novel about DevOps, co-authored by Gene Kim. It is discussing ideas of DevOps, proposing changes and metrics and also explaining methods and strategies to work from paralyzed IT workflows to an agile, DevOps centric company.

Locality & Simplicity

The ideal of locality and simplicity states, that every workflow should be simple, easy to follow and, in the best case, reproducible by a single person.

This means, that every worker in your tomato processing chain should know what happens with a fresh tomato, so it can become tasty tomato sauce. In the best case, the recipe and all needed steps can be reproduced in a small kitchen.

You might wonder, how this reflects in IT. Well, if you develop a software, you should be able to code, build, test and release your software locally on your machine. Necessary testing tools, knowledge about the pipeline and coding process should be present all the time.

But, this means even more. As yourself some questions:

How do you get knowledge about your pipeline?
Where do you document your software?
Do you always require somebody/something to test your code?
Where do you maintain coding conventions?

Here you also see the strengths of DevOps tooling and processes:

Git to check out your code locally
YAML pipelines, so everybody can read them
documentation IN the repository, so you don't need to look it up
containers, so you can run tests and builds without installing more software
mock data, so you can run your frontend without the backend

So, let's get simple and make coding less dependent on central services. You will see, this speeds up coding massively, and you will get a better understanding, faster.

Same for tomato processing. Having the recipe, a pot and all the spices on hand, will make it easy to replicate tomato sauce, even if central machines are broken.

Focus, Flow & Joy

Simplicity is not everything. You also need to have proper time for working and concentration. Instead of attending meetings and being interrupted by messengers, one will work way better, if you can focus on work.

Just think about the following situation: You start to cook tomato sauce and every 10 minutes, somebody is calling you and asking for your time. Even worse, if you don't know all the details, you will need to set up meetings to discuss the recipe, ask for the amount of sauce that needs to be made and fight for the budget that you need.

You can see exactly this in IT. People need to discuss tasks over and over again and are running into unsolved dependencies, blockers, and budget constrains.

This is not very joyful, isn't it? To fulfill this ideal for a single task, you can think of the following pattern:

you know why the task is important
it is designed to fit your expertise and knowledge
you can work without interruption and blockers
you can identify with the problem that needs to be solved
you get the support that is needed

When was the last time, all of these applied to your work?

And yes, occasionally you can mix in some fun tasks, for sure. This should be part of the process.

Improvement of daily work

This is a big one. It might be easy to say: "I am trying to improve, often.". But, how do you this? Do you measure your improvements? Which parts are you improving?

In DevOps, this is about:

improvement of processes (often through simplification, documentation, and communication)
improvement of tools (often by adopting better suited tools, reducing the amount of tools and updates)
improvement of work (identify and improve types of work; see "DevOps - 4 Types of work")

There are hundreds of ways to improve, but it must happen on a regular basis.

Reducing unplanned work, for example, is nothing you can do in one meeting. Instead, you need to start tracking the amount of unplanned work and see how you can reduce it or plan it for later.

There are methods like Kaizen, Scrum Retrospectives or regular feedback meetings that can be used for improvements. But you can also address this in measurements, strategical improvements and proper planning before starting to work. You might read books, learn new methods, tools, or design patterns.

Psychological safety

Psychological safety is a very huge thing. Let's start with an example. In a tomato processing plant, you can find lots of machines. These machines might hurt people, if safety measures are not in place. And let's be honest, nobody wants to see how people are hurt.

To avoid this, plant owners started to train their people. Most workers need to wear protection devices like working shoes or ear protection, if needed. Additionally, you can find warning signs, fences, railing and much more. All of this, just to protect the people. In some countries, taxi drivers and mail delivery services have to do alcohol tests before starting their work.

Well, how does this translate to IT? Very often, we don't use machines that can hurt us. But, the fear of failing on the job, losing the job or our status can also be an issue. If you always need to worry, what may happen if something goes sideways, you will take care of "making everything right", but you will no longer seek for innovation, improvements or major changes.

A psychological safe environment allows failures and learning. It also allows some freedom when it comes to problem-solving. Furthermore, the job you are doing will make sense, it will follow a purpose and has a direct link to a problem that needs to be solved.

Have you ever wondered why people are working on Open Source projects or follow an expensive hobby? Most do this, because they see some purpose, comfort, and self-fulfillment in these activities. Fostering an environment like this at your workplace will not only enhance joy at work, but also productivity and effectiveness.

Customer Focus

The last ideal of DevOps is Customer Focus. The customer in this case is more something like the user. Ask yourself some questions:

Does this solve a user problem?
Would I be willing to pay for this?
How can I get to know what my users want?
Is the requested feature really helpful for the described concern?

There is way more to it, and one might write books about customer focus and customer affection. Anyway, stay in touch with your users, gather feedback, understand their problems and provide a solution is key. Nobody is interested in features, that are nice to look at, but don't solve a problem.

The huge incentive here? Well, purpose. Solving a long-standing issue is enjoyable, for sure. Getting approval from a customer is even better. Hearing "This really helped me with my difficulty." is a huge motivation for basically everybody.

There is even more. If you solve enough customer problems, your product will be used more. Make your product enjoyable, convenient, easy to use and whatnot, but always try to solve the challenges of your customers.

Docs & Links

There are many articles about the ideals, let me link some that I found useful.

Conclusion

Now that I covered the 3 way to work, 4 types of work and 5 ideals, I will publish an article about the DevOps principles, soon. And I might also have a look at some useful metrics and KPIs later on.

Were you already knowing the 5 principles from the article? Are you following them in your daily work? If so, how do you do this? If not, what hinders you?

Let me hear your opinion and ideas about DevOps and the DevOps Ideals.