Realising DevOps is like Establishing a Culture
Updated: Oct 18, 2021
DevOps is ubiquitous now. Its adoption is becoming more and more inevitable irrespective of what your software engineering team makes. So, everyone is ready to have exciting and fruitful experiences. The reason can be many. It can be as simple as 'I want to do as everyone is doing it. Or, it can be a combination of one or more of the following or something else.
Get the pulse of the customer as quickly. Sounds like an incremental delivery. Yes, it is but DevOps becomes the highway for that.
Align with an agile mindset to create a strong culture of predictable software delivery
Apply left shift operator at a fast pace to avoid delayed discovery of issues by clubbing many other operations with DevOps. Some coins it as DevSecOps, SecDevOps, NoOps, AppOps, etc.
Reason can be anything! The intent is clear. And that is to establish a software culture capable to leverage an agile mindset for best outcomes by prioritizing customers first. And creating a culture requires more or less establishing 3 below (or core) steps:
Continuous Integration
Continuous Delivery
Continuous Deployment
The scope of this blog is not to figure out what the above 3 mean. The scope of the focus is to understand that why organization constantly struggle especially who have been in the industry more than a decade. The scope of the focus is to understand that why organization constantly struggle especially who have been in the industry more than a decade.
People know that DevOps is 3 step process. People know that there are X, Y, Z tools to assist each of the above 3 steps. People know that it requires establishing a chain of processes that is well documented. In spite of all these explicit known facts, organizations struggle! Few questions arise:
Why are many companies struggling to apply above?
Why does the organization take longer than anticipated time to realize a true DevOps system?
Why does DevOps create unrest among team members though everyone accepts on the paper that it looks promising and beneficial to everyone?
The answer is simple! Realizing DevOps is like setting up a new culture. Like a country or society can not establish a culture by building bridges, roads, factories, schools, etc. Certainly, these help to speed up an eco-system to create culture but do not create a culture. The same analogy more or less goes to DevOps. Tools like CircleCI, Jenkins, in-house developed automation system, github, etc provide you tool but does not create a culture for the software engineering organization. It is because creating a culture requires careful curation and aligning mindset. And every stakeholder needs to be truthful in setting up a culture. As truth is very simple to hear, accept, and advise but the most difficult to walk through. Yes, telling blunt truth sometimes can backfire and can harm someone significantly. So, there is a saying that it is OK to have a lie equivalent to a pinch of salt if it saves someone's life. But, it is not acceptable to distort the truth and portray false as truth. From our childhood, we have been educated to speak the truth but have not been educated enough about what truth is, how to use it when, why it is important to convey truth in an amicable manner, etc. The result is that we live a confused life, oscillating between what we should do and what we did and giving the benefit of doubt to ourselves. You will be wondering why I am giving this analogy. The answer is simple. The organization is doing the same thing while realizing DevOps.
The organization fails to communicate what DevOps is to its stakeholders.
Individual team distorts DevOps as per convenience in the name of adaption that DevOps is no more DevOps and eventually team fails to gain all benefit of CI / CD / CD. Everyone speaks DevOps, they mean different and execute it more in diverged ways.
Team decline to take accountability for failure as DevOps is meant to fail early, learn and move on.
Enough of problem space! Let us come to solution space. Let us understand what DevOps really means. I am not going to tell you anything new and there is high possibility that you might have heard the same many times. So, bear me for a repeat as it is needed to set the tone of the problem.
DevOps is based on CALMS principle.
C stands for Culture. Communicate, accept and adopt the change.
A stands for Automation. Use automation to simplify CI -> CD -> CD.
L stands for Lean. Be thinner, meaner and faster. Do small-small things in multiple iteration. It is again a mindset shift, especially for old organizations.
M stands for Measurement. Measure things to be more accountable and use it as feedback (like a closed-loop control system) not only for doing statistical computation. IF you can measure, you can tell yourself what to improve and henceforth how to improve. Again it goes to the mindset of taking accountabilities.
S stands for Sharing. Share the learning across the team to speed up adoption - again a cultural traits.
As you can see from above, only 2nd aspect is to do with the tool. Everything else is more about culture, taking feedback, and being more accountable to make ourselves better every day as we move on. We fail to realize: DevOps is a journey and not the Goal. And the journey is not going to be a straight line. It is going to spiral. You only can control the radius of each circle in a spiral as depicted below.
The more agile you are, the more focussed you, the smaller the radius. The smaller the radius, the lesser time you are going to realize DevOps. For that to happen, the organization and team will have to be truthful to accept failure and quickly fix it.
But most of the companies do fail because they do one or a combination of the following:
Create a DevOps team build of so-called DevOps engineers.
Fail to communicate about it and bring change in the mindset of the participant.
Hurry up to adopt some set of tools without planning how it is going to be adopted by the team.
Treat failure as a mistake like is being done in the traditional model. Eventually, it discourages accountability.
Expect change in few months. Culture does not change in few weeks or few months. It takes time.
Tweak process (especially by managers to meet short-term goals) to morph it in same old engineering process in the name of customizing or tailoring to meet organization needs.
Fail to communicate the value of automation to the team (especially to developers who are always measured on the basis of features they implement)
In fact, I will go as far as to say that tool is only 10-15% in the realization of DevOps. And, changing culture is about changing. It is all about an honest mindset to establish a new culture backed by a new set of processes, tools, and possible (if required). And it is not a mean task. To achieve this, the organization should first accept it. Here are some tips which can help the organization speed up the realization of DevOps.
Get sponsorship from executives. The water flows effortlessly from high altitude to low altitude.
Create an advocate for communicating about the benefits of DevOps which can be set of Architects or Agile coaches. I am not talking about the DevOps team here at all.
Promote the culture of early failure. The reward for the one who takes accountability for it.
Do not create a separate DevOps team. It is a common and big mistake made every now and then by organizations filled with intellectuals.
Embed the culture of DevOps in each and every service team
Spend proportionate energy in automation even if it slows down some of the features.
Hey, you are changing culture. Changing the culture is like seeding a bamboo tree that does not become visible for a certain time. But once it becomes visible, it grows 1 ft every day. The same is going to happen here. Do not take short cut to tweak the DevOps culture to morph into the same old culture. Otherwise, you will be doing the same thing expecting different results.