So, the time has come. Your organisation has finally made the decision. You will embrace DevOps practices to improve throughput and reduce costs. It sounds positive and upbeat. It sounds cutting edge and dynamic. It sounds amazing. You are looking forward to automating things. You grab your team and start getting them to automate tasks and pipelines. You focus on removing all the annoying things. This is awesome! You are really enjoying it. But wait, have you forgotten something?
Well, what is DevOps, really?
One could write a lengthy article on this alone. I will probably do so in the coming weeks. From a high level, DevOps is a movement of bringing the worlds of IT Operations and Software Development together, to form a new way of working. Although not that novel because it has been a concept for many years now … This sounds simple. Right? But there is more to DevOps than just amalgamating the functions of Software Development and IT Operations together.
DevOps itself is a culmination of practices, passions and cultures. It allows a company to have better and more granular visibility on its software development projects. Furthermore, it empowers developers to have more control of the development product from start to finish.
Now if you have invested time in either or both fields (Software Development and IT Operations) you would have garnered that these are relatively different worlds with rather conflicting opinions.
IT Operations is about being cautious, safe, slow, and secure. Development, on the other hand, is about learning from mistakes and failing quickly to be able to adjust, learn and correct. Sometimes this may mean things are pushed quickly, sometimes this may mean bugs are in production, but hey, it worked on your machine, right? It can cause some tension between the two “tribes”.
The bringing together of Operations and Development is like the meeting of two contrasting worlds. So how do you make this work, without an organisational, if not a world war breaking out? Prepare for keyboards and mice flying, and the product suffering for it in the meantime.
What can undo all your efforts…
From experience, the first thing that will determine whether your company’s approach to DevOps is a success or not is how well you can culminate a focus on culture within the company. That’s right; you can re-read that if you like, I said “company”.
You see, DevOps is not a team. It is not one engineer. It is not one function. It is an undertaking by every part of the company – the entire company.
How? Well, it comes down to four simple elements, which are interconnected. They are known in the industry as the principle of “C.A.M.S”. Allow me to delve into each element and explore why these four letters are important to explain the need for an open, innovative, precise and sharing, culture.
C – Culture
I am very aligned with the notion of ‘Culture is Everything’. Here at LimePoint, we are not only aligned with this, we live it each and every day. It is great to see that the principle of CAMS, too, commences with ‘culture’.
There is a reason for this. Culture underpins all other elements of the CAMS principle.
The culture element helps to understand the transition as we move away from the ways of yesteryears. We are all fallible; management, engineers and programmers alike. Yes, I said it. Don’t stop reading there! Believe it or not, we are all human. It is high time we start to appreciate and celebrate this, in every element of our interactions, with the people we spend a lot of our waking time with; our co-workers.
When I talk about a culture with
DevOps practices, I am not referring to the supply of muffin baskets in the tea
room and I am not referring to how many times there is a special themed dress
up day. Don’t get me wrong. These things are of course nice. However, I am more
referring to a company culture that allows people to learn, collaborate with
each other, uplift each other, be open and celebrate wins as well as failures
(yes, failures are actually things to celebrate, because we can learn from
them, and improve).
As you can see, it is about creating a culture that not only allows for failure
but celebrates it. It is about cultivating a culture of no blame. And this is
important, because in a culture of blame we cease, we stop communicating, we
think with fear, we have fear, in, and of the workplace. Apathy takes over.
This is not what DevOps is about. This does not cultivate sharing,
collaboration and learning. It fractures communication. It creates silos. It
does not uplift.
Sure, we should be cautious (and maybe even mildly fearful) of certain situations and factors. But, each other, we must not fear. Neither must the culture lead to a fear of management and leadership. There must be, in the culture, space where everything from inception, creation and eventually deployment is owned by the team that owns the product.
Not single individuals tasks. Not segregation
and silos. Rather, teams tasks. Collaboration and cooperation.
A – The Automation
Automation is usually what pings
to memory when you hear DevOps. However, it is the one factor that is executed
randomly in most cases. Automation should be done with clear directive and robust
purpose. Your culture must encourage it. It should inherently encourage
solutions that reduce resistance and friction on any development pipeline. But when
we talk culture, don’t just think of the software pipeline. I will get into
this in the next couple of points.
Your tasks around automation will consume large percentage of time, energy and
thought. So before you start coding, invest time in the strategy and the
planning. Don’t rush in. Assess the automation. Be open about your findings. Encourage
others to do the same. Then, as a team, get rid of those repetitive, annoying
tasks.
If you are unsure of how to share things that have just been removed from the
land of annoyance, get colleagues to present their findings. Celebrate the
collaboration, Celebrate their achievement. Always keep the attitude of
openness and sharing, and celebrate your wins, because now you can measure
their impact…
M – Referring to Measurement
What you measure and how you measure it are the most salient factors here. One that may make some people look confused at this page for a few moments. What if I was to tell you that your CPU load metrics are not as important as you deem them to be? What if I was to tell you that the culture of your company should not be focused on the infrastructure, but rather, on what the measurements can do for your end users. So if you can justify measuring CPU load because it would impact the end user’s experience, then put that CPU load measurement at the top of the list again.
But really work this into how it will impact the company, or more importantly the end user. Does high CPU load mean worse performance? Or does it mean that things are working as they should be? When you measure, make sure these measurements are translated to something that makes sense for what could affect the experience of your client. It is all about the end user. And if it is not, then strive to ensure that it becomes all about the end user.
How can you automate this to go out to or preferably be easily accessible by other members of the business who can benefit from the information? That must be the focus.
S – Referring to Sharing
How easy is it right now, for your whole company to get access to, and understand the measurements from your development environment? Or your production environment for that matter? Can your product manager look at a single point and know what is going on? Can the director(s), leadership or management of your company confidently look at a dashboard, a spreadsheet, or a web portal, and understand right then and there what is happening with the product? This is what sharing is about. Sharing of knowledge, sharing of information, sharing of IP, so that the company and all involved can make educated and well thought out decisions based on what they can learn from real-world information.
But sharing also has another part to it. Sharing of information between each other. The culture around DevOps should be shifting away from the old school chest beating of yesteryears that was often seen around the server-rooms, and more about sharing knowledge. Knowledge held by those with programming backgrounds and those with systems engineering backgrounds alike.
For this I like to refer people to a little video that Chef put out in 2016 staring Nathen Harvey, it was simply called “hug-ops” that basically had Nathen travelling around all the offices of chef hugging fellow staff members, why? To show that we all work together, and DevOps culture, if taken seriously, should allow all business units to do this. It’s a simple idea yes? But that’s the challenge, think about how you can implement more DevOps culture in your company.
What challenges will you have to overcome? Who will invite the change? Who will resist it? When you start to ask these questions you will come to understand that unless you have total commitment from your leadership, you will face an uphill fight. So work with your leadership team, show them this blog entry, and I wish you all the best with your journey.
When we introduce a culture to smash down the walls that used to exist, and remove culturally negative practices like task isolation, blaming, and bad communication practices, and start to implement things like hug ops (no I am not suggesting you hug your co-workers) we really do start to get we are working with people, not just sending something over the wall to a faceless department, we share in the teams discovery’s challenges and wins from start to delivery, and beyond.
There is almost a beauty in that when you think about it, people working together, uplifting each other and helping bridge knowledge gaps, no competition, no blaming, just cohesive teams sharing, building, and working together. Then and only then, will you be able to get the full benefits of being able to move fast, deploy quickly, share accurately, and most importantly enjoy what you are developing even more.
At LimePoint, we have all walked the same DevOps journey that you are probably on right now. Talk to us today for a confidential discussion of your current state and vision with our DevOps consultants.
