IT is part of the business

We are all familiar with the concept of DevOps, but it is very likely that many people think of it as a practice that affects only the programmers and the operations team, you may even think that it is simply about using certain technologies, but no; DevOps goes much further. DevOps is not only about development and operations, but it impacts the entire company, because it implies a change of mentality and culture and therefore, we are not going to talk about tools or enter to see the “pipelines” to perform automations or anything like that, but we will see some aspects of what DevOps involves and its overall impact on the company.

DevOps exists to improve the software delivery process, make it repeatable and unobtrusive, minimizing impacts on the normal operation of the company’s IT solutions. Mainly, what it does is that two work groups such as development and operations work in a joint and coordinated way, for example, sharing meetings, processes, metrics and objectives. So far nothing new that we have not read on multiple occasions, but by breaking these two silos and modifying their way of working, we will see how forces of culture change will be created in the company that will impact other departments and people, who must be added to this change of philosophy of software development.

Before starting to work with DevOps, we must think about something: if we want to implement this way of working, it is because we are currently aware that we have a problem in the delivery of developments or because we want to improve the process, and if we think we can improve the process is that it may possibly have a problem.  That said, to know the best way to mitigate the problems we have in the process, will be to identify them and know them in depth, this means that we must analyze the current software delivery process and see where there are difficulties and / or conflicts in order to address them. At this moment, some may think that in their process there are no problems and that it is very efficient, but it may be that they are not aware of them, that they do not want to recognize them, or that they do not know that the process can be improved; some tribes thought that the best way to defend themselves was with bows and arrows, until the competition arrived with shotguns and pistols; the result is well known.

One of the best solutions to identify the problems of a process would be to be able to read the thoughts of each of those involved in it; if we did this, we might find something like:

• [Business]: “I need this distributor to upload the invoices to the portal, and I’ve been asking IT for this functionality for some time. What must the development team be doing that they still don’t have it?

• [Developer]: “I have to generate code to implement all the functionality required by the company; I’m doing it, but I don’t understand why my code is not running in production yet, and business people call me to ask about their functionalities and won’t leave me work”

• [Operations]: “I have to keep the systems stable and free of bugs, let’s see if I can do few transports and this time the developers don’t break anything, I already have enough complaints from users and it seems that they program wildly without testing or taking security into account.”

• [Distributor]: “It’s been six months since they told me they would prepare the portal for me to upload invoices there, but I don’t see where this functionality is.”

As we can notice, everyone sees the situation from their own point of view, and everyone’s thoughts and feelings are the ones that give us clues on how to improve the process. As we cannot yet read people’s minds, the best thing to do is to put these thoughts in common and thus analyze the processes.

To analyze the current software development and delivery processes, it is best to hold workshops where the people involved in them explain their vision and feelings, what problems they see and how they would do it to feel better.  Among the people to invite to these workshops, there will of course be developers and operations people, but also business people (and even people from external companies), who are the ones who give us the requirements and the end users of the solutions.

I would like to note three things from the previous paragraph:

• We talk about the vision of the process because each person experiences the process and its problems in a different way, and these sessions will allow us to “walk in the shoes of the rest of those involved”, to get to know other points of view. All opinions and comments are important, because sometimes, we are not aware that when we do something, or we do not do it, or we do it late, no matter how small, it can impact much later in the process. For example, something as simple as not having the invoices entered in the system on the indicated day and with the established format, can make the people in charge of closing the month work more hours than necessary, and what for someone is just a few minutes, for another person can turn into hours of additional work. Having a complete view of the process and knowing the pain points of the rest of the people involved, makes us empathize with them and, in the future, the process flow will be much more agile, while many more ideas for improvement arise.

• That in these meetings there will be many people involved, from different departments (sometimes from different companies) and of different categories; this can make it difficult to dialogue and sincerity, so it will be necessary to previously agree on certain rules (some of them are common sense, but better to agree on them) when analyzing the problems, so that it is not a battle of blaming or disrespect. We must not forget that we are here to see the problems that each one of us encounters and to see how to improve the process so that everyone wins.

• We have talked about feelings, because when the workshops are carried out, we will not only talk about the procedure, but also about the feelings of each of the people who interact throughout the process, a customer journey of each of the actors involved; and we must be prepared for the best and the worst; a word that comes up many times is “frustration”.

As we can see, we are talking about including people from all over the company and inviting them to comment in a transparent and open way their impressions about the process and those responsible for the process to learn and improve with them, this is a change of mentality in almost all companies. As for how to conduct these sessions (as many as necessary), the best way is physically in a room (when possible) or at least with video call, avoiding at all costs the use of voice only. In the case of video call, the ideal is to have everyone with the cameras on and always focused on the activity, pausing to attend to emails and important issues that may arise. The environment should favor open participation, for which we will use some blackboards and places where we can stick papers with notes. To make the sessions more dynamic, we can use some techniques such as the Starfish, a smaller variant such as StoStaKee, the sailboat, or the value chain analysis, a technique taken directly from industrial processes. There are many methodologies that can be used to drive the change process such as the ADKAR Model.

Since we are going to include people from other departments in our working groups, we will have to ask their managers for their availability (we have already made it clear that DevOps does not only affect developers and operations), at this point we may find ourselves in a situation similar to the one we find with the adoption of any type of innovation, process or technology: Departments and people who have no objection from the beginning that they and their teams participate in the sessions because they see a clear benefit for the company (innovators and early adopters), departments and people who will participate as they see others participate (followers) and departments and people who will be reluctant until the last moment and who will even preach the end of the world for the introduction of these changes (laggards). Our mission is not to disappoint the early adopters, convince the followers and ignore the laggards.

The introduction of DevOps in the enterprise is not a one-day thing, it is a long-distance race, so we need the confidence of innovators and early adopters not to wane, because they will serve as evangelists and will get us more people who want to join and contribute in this initiative, And for that, we need to give them “something” so that they see that they have not been wrong to embark on the DevOps adoption process, that they have bet on a winning horse, and although sometimes we do not have much to offer them, especially at the beginning, transparency and information is always good.

Once we have collected the problems and concerns about the software delivery processes, we must analyze them to see how to eliminate or minimize them through DevOps, thus generating the plan for implementation. Some of the problems we will encounter are:

• Releases that are too large with too many functionalities.
• Too much time passes from the time a bug is discovered until it is fixed.
• A lot of time and decisions at each step of the process
• Too much red tape
• etc.

They are the usual suspects.

When making the implementation plan, it is good to take it as a business, setting a mission, a vision and objectives. Once we have them defined, it is good to contrast them with other departments to check that they are aligned and with the marketing and communications department to help us to do some internal publicity so that everyone knows about the initiative, writing a newsletter, putting up posters with some of the objectives, etc.

Communication in the DevOps implementation process is very important, we must ensure that everyone knows that this process is underway and for this, we will have to do public relations work, sessions explaining it to the departments, advertising it, etc. so we get visibility in the upper layers, that those who are involved remember that they are part of it and that more people want to get involved. In this sense, we can also establish the figure of the DevOps evangelist, who helps other departments to understand what is happening in the company in terms of solution development, how it will impact them and what the future will be like.

An important topic to keep in mind when informing is to be consistent and always use the same words, so it is good to create a glossary of the words we will use, explaining what they are and what they are not, so that there is no ambiguity and that if someone talks about a release, we all know that it is “an installation or deployment of a block of code in an environment (productive, test, etc)” and it is not, for example, “an operating system version upgrade”.

Inform, inform and inform

It is very important to keep everyone informed and up to date, and I am not only referring to those directly involved in the program, but also to those who are impacted by its deployment; in other words, to the whole company. The level of information does not have to be the same for those who are involved firsthand and for those who do not want to know anything about the program, for example, it would not be a good idea to send a daily email with information to a person who is reluctant to adopt DevOps, because it would be counterproductive.

How to inform without being intrusive? Well, it will depend a lot on each situation, if the budget and the environment allow it, the installation of screens in some rooms, such as the coffee room, showing evolution indicators and news could be a good option.

If we do not have budget for it or circumstances do not allow us to do so, we can look for other ingenious ideas such as posters with a message about the DevOps implementation program and a QRCode with a link to the evolution indicators control panel or a section in the company’s publications.

We must report everything, and things do not always go well, but in that case, we will also report. If we have asked for transparency and acceptance from the rest when we have done the process analysis workshops, we must lead by example. DevOps is also about transparency and trust. When there are accidents or errors, they will be communicated, they will not be given more importance than they have and we will not accuse or blame without reasons, they will be analyzed and we will learn from them, continuing with the process. It is one more step in the change of mentality, going from accusation to learning.

And we must remember that “no news means… no news”, so we must advertise and inform; even historical brands of soft drinks with dark color and bubbles remind us on television of their existence through advertisements. But to inform, inform and inform, we must measure, measure and measure.

Measure, measure and measure

But what to measure?

The quick answer is as much as we can.  There are some common DevOps metrics such as:

• MTBF (mean time between failures)
• MTTR (Mean time to resolution)
• Bug scape distance
• Commit rates
• etc.

This can be seen by developers and engineers as spying on them and not trusting their work, and nothing could be further from the truth, so we must be careful when transmitting the messages and do it in the right way, as these measurements will help them to measure the performance of their developments, will help them to eliminate duplicate code, etc. In short, they will help them to improve.

In addition to these indicators, we can take advantage to expand the range of measurements, for example, when the software is deployed in production and begins to have performance failures, problems begin to know if it is part of the software platform or the infrastructure and networks, some internal measurements of the application can help a lot. So, a good rule of thumb is to measure everything you can, just as a formula 1 is full of sensors that emit at all times the health of each part of the car, so should be our applications. We can incorporate logs where we store response times of each of the parts of the code and from time to time send them to a central system that can analyze these logs and graphically paint the performance and send automatic alerts when substantial changes in performance are detected; thus, it will be very easy to detect changes in performance after each deployment we make, without having to wait to find out when the end user complains.

And if we have mentioned that DevOps is not only technology and that it has a global impact, we can also to measure the impact it is having on people throughout the company, this is a little more difficult to capture and measure than the time between deployments, but it will give us a view of the footprint that DevOps is leaving on the most important asset: people. One of the best ways to do this information capture is to periodically conduct short interviews or make available questionnaires where questions such as:

• Do you think you have the right tools to do your job?
• Do you think the collaboration between business and development is effective?
• Do you think DevOps is improving software delivery processes?
• How would you rate continuous software delivery?

It is very important that the questions are not long, otherwise, people will not answer them, likewise, it is best that the answers are closed, for example, scales from 1 to 5.

All these metrics will help us to know how the DevOps implementation is evolving in terms of processes, performance and people, and to be able to act in case of unexpected drifts. If you don’t measure it, you can’t control it.

DevOps is something alive, there does not come a time when we can say that it is implemented in the way we work and we forget about it, but we must maintain and adapt it. There will always be new technologies, new processes, new challenges that we must face and adapt our way of working to them. In this sense, we can see the DevOps adoption process as that of a house in the country that has been there for a long time and has not been taken care of, where we may find dust and weeds, marred paint, etc. During the first months, we will be removing those weeds, painting the house, or maybe changing some windows. What is clear, is that if when we think it is finished we do nothing more, in a few months we will have weeds and even leaks, so we are reviewing the state of the house and fixing what needs to be fixed and improving what can be improved (maybe a dwarf in the garden, who knows). In the same way, the environment in the company will change, and if we neglect the DevOps processes, we can lose the road we have walked, so we must monitor and adapt the processes to this changing environment. One of the ways to do this is through Deming cycles (by Edwards Deming) or PDCA cycles (Plan, Do, Check, Act) through which we can monitor and improve processes, in a simple way and reminding us that we should not rest on our laurels thinking that everything will be fine from now on.

With this brief DevOps implementation journey, we have been able to see that something that we thought only affected a couple of workgroups, really affects the entire company and that although at the beginning it may be an overexertion for workgroups outside the core of development and operations, the benefits in the long run are for the entire business. We can say that DevOps is not

but