Life at Cloudibility (X): DevOps? They should do it, not us!

logo_cloudibility_rgb_transparent_square_smallThis is, what you have to take care of when trying to establish a DevOps-culture: Many, if not most, people being affected by a DevOps-approach, will agree with it. At least as long as it does not force them to change anything and as long as they can sell it to their customers or supervisors since DevOps is very popular these days and is to be implemented by them, not by themselves.

Just last week, we had such a situation: We are in a short-term project with an enterprise customer. We have been hired by the vendor doing operations for that customer in a somewhat-CloudNative-environment (they run OpenShift on BareMetal-machines).

The end-customer sees a lot of – let’s call it that way – potential in the collaboration with the ops-vendor. Or to put it in clear words: There is no transparency, no knowledge-sharing, no automation, no versioning and no proper mindset in place at the ops-vendors teams. As a result, a lot of the infrastructure is somewhat running, but not even close to the standards, the end-customers expects. Rightfully expects, in my opinion.

This was the situation when Cloudibility experts were hired to analyze and fix errors in the environment, the software, and the collaboration. We proposed an agile DevOps-based interaction- and operations-model to our customer (the ops-vendor) and discussed chances for such a model with the end-customer as well. Both parties appeared to be very in close in their expressed opinions – yes, they all want to switch to a DevOps-approach.

One week later…

One week later, one of the two companies still sticks to that opinion, the other one does not.

The ops-vendor changed his mind since we perhaps were too successful and identified as well as fixed a lot of improvement-opportunities. He simply does not see the need to change his processes (which lead to the situation we came in) and his way of executing anymore, since the fixes are actually working and the customer appears to be satisfied.

DevOps now is to be executed by his customer, he will be participating in this „a little bit“ (quote), but only „as long as it fits into our processes and does not imply ourselves to change our approach“ (another quote). Plus: „We want to keep our internal approaches a secret, the customer does not need to know about them or can even expect us to adjust to his way of interacting – he is the customer, we are <Company-Name ommitted>“ (quote). And: „Don’t forget, we are not even required to have a logging and a monitoring in place, by the terms of the contract that customer signed“ (quote).

What could possibly go wrong with such a mindset?

Frankly, we expected this behavior from this customer, but it is frustrating nonetheless since they offer a CloudNative and Enterprise-ready environment and operations-model to their customers – and simply can not deliver due to having the wrong mindset and approaches, which gets only visible once a customer signed the contract (we have seen this several times with this customer). They execute IT the old-fashioned ways, having SDM (Service Delivery Managers), steep hierarchies and ITIL-processes in place, instead of DevOps-managers, experts, and an agile operations approach.

So, be careful when someone tells you about executing DevOps. Chances are, all they want is to get their backs covered and they will refuse DevOps as soon as it would imply to change something in their own processes and approaches.

Are we stopping to help such customers and to propose modern, lightweight, cost-efficient and adoptable processes and approaches?

Never ever!

And we will – of course! – successfully end our mission in that specific project as well. But it is kind of sad to see a chance for establishing better approaches and better processes pass by just because one of the involved parties does not want to change anything on their side.

Sad from a mindset’s perspective. From a commercial perspective, it is not: We are happily there to help with the next failing project. Again.

What is… DevOps?

Devops-toolchain

By Kharnagy – Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=51215412

Ok, I get it. You do DevOps.

  • Because you shut down your VMs at night. Automatically.
  • Because you have a Jenkins-installation.
  • Because you are moving to a cloud environment.
  • Because you have set up a „DevOps“-team.
  • Because you have a lot of meetings with stakeholders.
  • Because you want a Development team to run a software since the approach is often described as „You build it, you run it“.
  • Because you know about this nifty image on top.

Turns out: No.

You don’t do DevOps.

You just shut down your VMs at night, you just happen to have a Jenkins-installation, you’re just moving to a cloud environment, etc.

But this is not DevOps. At least not in the sense we at Cloudibility understand it and explain it to our customers and set it up with them. To us, DevOps is not about any specific technology or setting up a team.

DevOps is a mindset.

It is an approach to thinking about, developing and running software collaboratively. It is about the way you interact from the start to the end of a project with each other. It involves getting rid of this „throwing over the fence“ mentality. It involves a process for collecting and maintaining knowledge in an ever-changing team and agile approaches to development and operations. It is about the way a team is set up and how it evolves, it is about the way we set up and execute operational processes. DevOps even is a way to organize collaboration in a whole company.

And, DevOps is a culture.

business-team-meeting-boardroom_4460x4460

Photo by Matthew Henry from Burst

So, DevOps is way more than putting Dev and Ops on the same table. Or than moving into cloud environments. Or than being agile. Way more.

In the following months and weeks, I will give you insights into our approach to DevOps. I will give you some tips and hints. I will help you to see the whole picture. I will do this on a per-issue and per-aspect base, and it will be a loose series of articles.

Stay tuned!

I have an open slot at 6.30am…

This has been said just seconds ago in a meeting I am currently attending. We’re not talking about freelancers here, but a pseudo-agile project with an enterprise customer.

See the problem?

Agility is not about having meetings cluttered all over the day, but efficiency. If your calendar is blocked so extensively by meetings, then perhaps, perhaps something is wrong.

Pro-Tipp: Change it. Cancel the unnecessary or unproductive meetings. Only attend meetings making any sense. Do not attend meetings for the sake of attending them.

Pro-Tipp 2: Participating in Scrum? Only do the scrum-stuff: Daily, Retrospective, Review, Plannings and perhaps Estimation meetings. All the other meetings should be obsolete if you communicate transparently. They should be attended by some POs or Architects, but not by every other person participating in the team.

Pro-Tipp 3: Participating in Kanban? Only do the minimally required stuff: Daily, Jour-Fixes or Reviews, Plannings. Work with your kanban board. All the other meetings should be obsolete if you communicate transparently. They should be attended by some POs or Architects, but not by every other person participating in the team.

(Hmmm, that’s pretty much the same content in Tipps 2 and 3. Coincidence? I don’t think so…)

Pro-Tipp 4: Get your stuff done!

Pro-Tipp 5: Get. Your. Stuff. Done!