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 *

Publicaciones Relacionadas


Comunicate con nosotros

Estamos acá para acompañarte en tus estrategias de  Transformación Digital.

Cualquier inquietud no dudes en comunicarse con nosotros.

  • Solicitar propuestas
  • Preguntas sobre nuestros servicios
  • Requerir consultoría profesional