Want DevOps Automation? It’s People Before Pipelines – InApps Technology 2022

CloudBees sponsored this story, as part of an ongoing series on “Cloud Native DevOps.” Check back through the month on further editions.

“When you say DevOps, everybody really opens their eyes really wide,” noted business agility consultant Almudena Rodriguez Pardo, opening her 2018 Agile Tour London Talk about the human side of DevOps automation.

Automate everything! This is at the crux of continuous delivery, right? Speaking from more than 20 years in the developer experience space in the telecommunications world, Rodriguez Pardo says, besides automation, you have to look at the people who are planning and driving that flow.

Today we reiterate her small steps that can be applied to any kind of organization starting with or already struggling through a DevOps transformation.

What Is DevOps Anyway?

“Whatever definition you might have, you are not wrong because there is no official definition of DevOps.”

Rodriguez Pardo pointed out how agile has the Agile Manifesto to offer guidelines to agile software development, but there is no such thing for DevOps, which means that no one’s definition is wrong. We agree it means Development plus Operations, but that’s where clarification ends.

“This is quite a problem actually because everybody is talking about it and everybody means something else,” she continued.

So for the context of her talk, she offered her favorite DevOps definition by VersionOne: “DevOps is not a tool or a process, but a practice that values continuous communication, collaboration, integration, and automation across an organization.”

This fits well also because no one can really agree on the definition of the D (“delivery,” or sometimes “deployment”) in the CI/CD value of DevOps either. Everyone seems in accordance that the first stands for continuous integration, but is the CD continuous delivery, deployment, design or something else? Often it means all of them.

What Rodriguez Pardo did in her talk by establishing a definition at the start was to remind us that, because there is no standard definition, this is the first point of conversation when approaching any DevOps transformation — start by clarifying what it is you are even talking about for each department.

“It includes communication, collaboration and integration, not only automation. That’s something I really like about it,” which are the factors Rodriguez Pardo focused on for deciding what to automate.

Most companies undergoing a DevOps transformation have already embraced the Scrum framework — with clearly defined roles of Scrum Master, Product Owner, and development teammates — which she says works well if you assume the product goes directly into the hands of the customer after it leads the Scrum process. This is rarely the case. This is never the case when you’re talking about the complexities of telecom companies.

In fact, Rodriguez Pardo dubbed Scrum and Kanban simply “agilization” of Waterfall project management.

“Now we are heading forward. What we are trying to do with DevOps is that we are still trying to have our interactions with excellent, quality working code, but we also take care of the environment that’s going around. So it’s not just fixing the code and putting it out the door. We need to secure the environment for operations,” she explained.

She says continuous delivery pipelines differ widely per sector.

The majority of tech-backed orgs now have continuous design and integration, but continuous delivery, continuous deployment, and continuous release varies per company. Rodriguez Pardo said if you are Amazon or Spotify, you may be delivering three times per minute because you are directly delivering to your customer. However, if you work at a telecom and you are working with a network operator countrywide, with a few thousand people talking at the same time, you may not want continuous release.

“There are several pre-production and production steps which you might apply,” she said, referring to companies in what she calls high-complexity sectors, offering the example of Ericsson below.

She pointed out how at Ericsson they have a continuous improvement and feedback loop integrated into their DevOps flow. Whatever is discovered in pre-production is factored into the next design iteration.

How continuous is continuous? That again varies by company and sector. Ericsson, in this case, was able to move from releasing every six to 12 months to monthly. Rodriguez Pardo admitted it wasn’t continuous but for releasing into a UK-wide or even Europe-wide network, that’s quite good.

“It’s not about how continuous you are. It’s about what are you heading for,” she said.

“Continuous everything” can be too ambitious for most companies. However, advancements like virtualization and containerization mean that every developer can get a “pretty operational environment.” This will act as an important DevOps accelerator in a lot of companies.

Mapping Your Continuous Pipeline on Human Interactions

The first step toward DevOps is automation. Rodriguez Pardo says that sounds logical but it’s usually not. In fact, she cited a survey of enterprise IT in Europe, which revealed the majority of companies have only 20 percent automation.

She says she talks with companies that say they don’t have automation because they don’t have the budget for it.

“Automation is not an option,” she countered, sharing an overwhelming image of almost all the DevOps tooling and orchestrators to combine them, pointing out how much of it is the significantly cheaper open source.

Rodriguez Pardo says there’s no excuse not to automate, but just don’t forget the human factor of that automation.

One of her telecom clients has to work with different operators. One LatAm operator said they only wanted to work with one particular person so that person had to be added to the DevOps plan. Then, they had to adapt to different operators’ architecture. Then they had to test in different structures and make changes to the network. They also have an integration protection ahead because the provider wants to see a change within its own environment before releasing.

“Security, testing, development, operations, integration — whatever your continuous pipeline is like, make sure that the complete pipeline of quality code is to make the customer happy in the quickest time possible.” — Almudena Rodriguez Pardo

A CI/CD pipeline has to include the customers and the distance and connection points to them.

She said in this situation you might even have interlopers like where something needs to be adapted or you may have a developer travel to the premises of the customer. She calls this “manual delivery,” which is the antonym of automation, but doesn’t negate its value, since the whole point of DevOps is customer pleasure.

“Because by bringing your software personally to your customer, you sit with him, you hear his comments, you hear him bitching about something he doesn’t like. You can have empathy and learn pain points,” Rodriguez Pardo said.

The wider you map that feedback loop, the more operations are included in hearing it. And with everybody listening, you uncover sometimes absurd incongruities. On one team, devs had KPIs (key performance indicators) to make as few mistakes as possible, while testing had KPIs to find as many mistakes as possible.

“Can you imagine the volleyball going back and forth? ‘No you’re wrong.’ ‘No your test was wrong’.”

Department managers then did something “revolutionary,” Rodriguez Pardo quipped, and they talked to each other, deciding on common goals.

DevOps: A Balance of Specialization and Cross-Functionality

Rodriguez Pardo continued, “That’s what Scrum was for. It was not only about sitting together. It’s about sharing, going to a common understanding, supporting each other, and creating cross-functionality.”

Whether you have Scrum, Kanban or something else, she recommends including Operations on those teams in order to unite around shared objectives.

She says DevOps isn’t just about breaking down silos, but about developing skills. This usually involves specialization in verticals, but then having a general understanding of everything horizontally, from a brief comprehension of tools to which team does what to transparent goals and tracking.

To achieve this, she suggested you can kick this off with small testing experiments that are related to the developers or give everyone some basic workshops in Jenkins to cross-pollinate continuous integration.

Rodriguez Pardo says the purpose is to attract some interest and give them a taste, applying ideas like communities of practice and other cross-company guilds.

The end goal is best illustrated by the Spotify diagram below.

“With the operators’ support, they are aligned. They are mature within the teams and understand what they have, what they don’t have, and where they can collaborate,” she said, adding that everyone is autonomous, secure, and heading toward delighting the customer.

In the end, DevOps is just about people, both the customers and the teams. When hiring for the cultural change of DevOps, you are no longer just hiring the best in a certain language, you are hiring a personality and how she can adapt to change and work well with not only her own team but with other teams as you head toward cross-functional knowledge.

“There’s one thing we cannot forget is that whenever it looks like a technical problem, whenever we think we have a technical issue, it’s always a human problem at hand.” — Almudena Rodriguez Pardo

List of Keywords users find our article on Google: