The Worst DevOps Flaw
Juan Andrés Ochoa
Juan Andrés Ochoa
Fundador y CEO de Castor Evolución digital. Autor, podcaster, speaker, músico, navegante y filósofo novato.
El peor defecto de Devops The Worst DevOps Flaw

Would you help me?

Falling in love with DevOps is easy when you understand it and its purpose. It happened to me, I confess, and because I got here, I’ll tell you even more:

  • In the current context, I consider that software is one of the great facilitators or one of the great levers for the development of organizations.
  • We have decided to carry out projects or initiatives –in Castor– where mentality and methods are worked on with the paradigm of continuous delivery[1]
  • To have continuous delivery in software, DevOps becomes necessary. It may not be all the technical elements that make it up, but ultimately, the way of acting and thinking that it promotes, yes.
  • Organizations must scale continuous delivery at the organizational level. It is one of the most critical enablers to achieve business goals, such as EBITDA generation, market share percentage, customer satisfaction, employee satisfaction, or sustainability.

With all of the above in mind, let me state that continuous delivery and DevOps are undoubtedly the main drivers of innovation and business development in the group. However, even so, promoting your application in the market is not easy.


So What is the worst DevOps flaw?

Its name.


You may be thinking that I’m a little crazy, but not that crazy. Or better yet: yes, maybe yes, but for other reasons.

When I speak to an organization’s CEO or senior manager about digital transformation or business agility, I see indescribable emotion in their eyes.
Who doesn’t want to be agile, transform, look like Google, UBER, MercadoLibre or Amazon -the divas of the moment-? I assure you that fewer and fewer directors, at least in medium and large organizations, are resisting these possibilities.

On the other hand, if what I do is mention DevOps and I try to explain that that name is the integration between Development and Operations, that emotion fades, the attention is lost and the topic lasts little or nothing.

My approach to the subject

For this reason, I have chosen to speak instead of DevOps about continuous delivery that brings us closer to our goals.
And, to make myself clear, sometimes I use this example: What if a bank that wants to be agile and a digital benchmark could take 14 months to launch a new application and, being not enough, spend 4.5 more months updating it? or: Can they spend four months to create a business case, plus two months approving it, and another two months working to develop it and then 15 days to deploy it?
So when I have their full attention, I would throw the critical question at them:

Is that agility?

Without waiting for their response, I tell them with determination: No, it is not agility, even if they apply Scrum –strictly following the guide– with all their roles and events, it is not agility, nor digital transformation.
Then I talk about continuous delivery, a brutal enabler consisting of mindsets, methods, and tools, allowing you to get to market faster, with higher quality, less effort, and more employee well-being. And that continuous delivery is based on something initially technical called DevOps.

As soon as I notice that the emotion begins to appear in their eyes, I offer to tell them in detail, and from that moment, I can start a triggering conversation.


My reflection on the DevOps flaw

Although it is an exciting process that has allowed me to understand many things, the truth is that it would save me from all this path if there were a name with more force, more imposing, more diva, and that’s when a question arises:

Is it worth renaming DevOps in a way that does more justice to this brilliant and necessary thing that enables continuous delivery?

For example, can I give you a small and forceful explanation that always accompanies it? A last name? What you think?

Would you help me?

If you can, I would appreciate your response to this post. Together we can build more community and knowledge.


[1] Continuous delivery is a set of capabilities that allows us to achieve changes of all kinds (including new features of products or services, configuration changes, solutions to incidents or errors, and experiments to production or users) quickly and sustainably.

Source: Accelerate, by Nicole Forsgren, Jez Humble, and Gene Kim.

The cover image was taken from: Cartoon vector created by vectorjuice –

Te invitamos a que nos sigas en nuestras redes sociales: LinkedIn, Twitter y Facebook.






Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *


Contáctanos, nos encantará saber de ti.


Agilidad empresarial - Business Agility
Felipe Mejía

Business Agility: adaptation and people

Business agility: adaptation and people Agility is the ability to adapt quickly in a constantly changing environment. In the digital age, this means that organizations

Leer +
Entender la Agilidad - Understanding Agility
Felipe Mejía

Do we really understand agility?

Understanding Agility The business world is changing rapidly. It’s no longer just about having the right product or service; it’s about having the right distinctive

Leer +
Resultados emergentes
Juan Andrés Ochoa

Emerging results

I observed that by reading the book La estrategia emergente, by Alejandro Salazar, I generated significant mental connections between agility, digital transformation and emerging results.

Leer +
© Copyright 2023 | Castor Evolución Digital | Todos los derechos reservados