Entendiendo lo que se creó, como consecuencia de dejarlos en el cajón del olvido

Algunas veces sucede que los gobiernos de turno tienen que pedir disculpa por los errores, agravios u omisiones de gobiernos pasados. Y quiero comenzar este post, precisamente pidiendo una disculpa, por las omisiones ocurridas por los primeros agilístas, los que siguieron y los que continúan, aquellos, quienes al ir introduciendo frameworks, bajo el paraguas de la agilidad; Fueron colocando las primeras partículas de vida, de ese nuevo monstruo (increíble que así, lo vean algunos en la actualidad), que no podemos omitir el día de hoy.

Teniendo en cuenta la popularidad de esta serie, (Stranger Things) y con el permiso de Netflix, he decidido llamar este Monstruo (repito increíble que así, lo vean algunos en la actualidad) el Demogorgon de la agilidad, ¿porque digo de la agilidad?, porque si en vez de estar preocupándonos en sacar e implementar cada vez más framework nuevos, debimos habernos concentrado, desde el comienzo y continuar haciéndolo, en lo que Alistair Cockburn, llama “El corazón de la agilidad”; simplemente, “Colabora, Entrega, Reflexiona, Mejora”, ya habrás dicho todo lo que necesitas decir y hacer. Cada uno se despliega en infinitamente complicadas habilidades, acciones, herramientas, y demás. Cada uno es rico en matices. Y, aun así, podemos replegar todos los matices y complicaciones, y recordarnos a nosotros mismos: “Colabora. Entrega. Reflexiona. Mejora.” (párrafo tomado directamente de la página: https://heartofagile.com/el-corazon-de-la-agilidad/)

Retomemos lo del Demogorgon, llamarlo así, no es casual y lo comencé a hacer, después de realizar una charla sobre DevOps, porque se me ocurrió esto, mi querido amigo lector; fue por lo siguiente:

Resulta que “La finalidad de DevOps es crear las condiciones adecuadas para la colaboración entre los departamentos de desarrollo y de operaciones”. Momento, ¿eso y mas no es lo que buscamos al habilitar la agilidad en una organización?; “DevOps busca mejorar la agilidad del Servicio de entregas en TI; haciendo énfasis en la comunicación transparente, la colaboración junto con la integración entre el software de Desarrolladores y las operaciones de TI; además reconoce que los desarrolladores y los operadores de TI no son grupos sin relación que pueden que interactuar entre sí, pero no realmente trabajar juntos. Por lo tanto, ayuda a la organización a crear servicios TI y software de manera rápida, lo que resulta en la reducción del número de iteraciones. Para esto es fundamental tener las herramientas adecuadas y combinar servicios, DevOps se preocupa por si una herramienta provee la capacidad de interactuar y funcionar eficazmente”. Como diría el conocido futbolista colombiano Carlos el “pibe” Valderrama: “Eche espérate ahí, cógela suave” (disculpen la expresión, se me salió parte de mis orígenes de la costa atlántica colombiana – Es algo similar a decir: “Toma las cosas con calma”). DevOps busca “mejorar la agilidad”, interesante, pero yo pensaría que mas que mejorarla “Contribuye a que se continúe habilitando la Agilidad”; por otro lado, acaso la agilidad, ¿no nos invita a tener un pensamiento sistémico y trabajar de manera colaborativa?

Ahora bien, también llamamos a DevOps, una cultura, no será mas bien que DevOps deberá ser parte de la cultura. Entendiendo eso sí:

  • DevOps NO es una estrategia para todos. Hay gran diversidad de tecnologías empresariales y drivers a ser considerados para establecer la estrategia de adopción para DevOps.
  • DevOps NO es automatización, implica automatización. Pero es más que automatización
  • DevOps NO es una herramienta, a ser implementada. Aunque hay herramientas que son usadas en DevOps, no deberíamos limitar su alcance a herramientas específicas como Chefs o Jenkins. Esto limita su alcance, como si una sola herramienta de automatización se equiparara con DevOps.
  • DevOps NO es equipo de trabajo nuevo y separado de las demás áreas de TI. Tener un equipo DevOps separado, anula el propósito de evitar las posibles fricciones y falta comunicación entre los desarrolladores y operadores de TI ya que crea un silo más.

Hay que entender que cuando hablamos de DevOps, continuamos hablando de agile, ¿por qué?, porque al hablar de DevOps estamos hablando entre otras cosas de:

  • Alta cooperación (un solo equipo).
  • Responsabilidades compartidas y riesgos.
  • Entrenamiento continuo.
  • Comunicadores recompensados.
  • Falla= Descubrimiento y Mejora.
  • La innovación continua.
  • Equipos Empoderados y Comprometidos.
  • Iterar de manera más rápida durante la fase de desarrollo.
  • Evitar la fricción entre los desarrolladores y operadores tanto como sea posible.
  • Garantizar la transparencia e integración entre el equipo de desarrollo y operaciones.
  • Establecer procesos de negocios alineados en flujo “justo a tiempo” (JIT por sus siglas en ingles).
  • Maximizar los resultados del negocio, tales como incrementar las ventas y la rentabilidad, mejorar la velocidad del negocio, o minimizar costos operativos, al alinear los procesos empresariales “justo a tiempo” (JIT).

Vuelvo y pregunto, ¿eso no es lo que buscamos al habilitar la agilidad?; ahora entrando mas en la llamada cultura DevOps encontramos que sus pilares son: los flujos de valor, la Visibilidad y contexto conectados, la Mejora del cumplimiento, el control y la seguridad. Sigo pensando, ¿eso y más, no es lo que buscamos al habilitar la agilidad?

Bueno pero algún DevOps lover dirá, “ah, pero en DevOps tenemos nuestros propios principios”, que son:

  • Acción centrada en el cliente.
  • Responsabilidad de extremo a extremo.
  • Mejora Continua.
  • Automatizar todo lo que se pueda automatizar.
  • Trabajar como un solo equipo.
  • Monitorear y probar todo.

(Aquí me excuso si son más, y yo no los encontré), vuelvo y repito, ¿eso y más, no es lo que buscamos al habilitar la agilidad?

Ya para ir cerrando este post, mi querido amigo lector, que en aras de seguir dándole vida al Demogorgon, noto con preocupación como ahora buscan la forma (algunos claro está),  de querer ver por separado y unir algo que en esencia es una consecuencia del olvido, realizado en la otra. Y es esto:

Con lo que, al buscarle más explicaciones complejas, se ha creado esto:

Mi querido amigo lector, no quiero que te lleves la impresión que estoy en contra de DevOps, por el contrario, veo en él, la oportunidad de enmendar un error que aun se sigue cometiendo y es ver por separado cosas que, desde el corazón mismo, el core mismo, si así lo quieres ver; NO deben verse por separado, ni pensar que son culturas distintas. Lo digo, porque ahora resulta que se creó esto:

Si seguimos así, a este ritmo estaremos creando cosas como DevSecOpsRRHH, DevSecOpsRRHHSALE, DevSecOpsRRHHSALEUX. Y quien sabe cuántas más.

Así es que mi querido amigo lector, mi querido compañero del área de operaciones y mis queridos amigos de las otras áreas organizacionales, recordemos que al final, debemos trabajar unidos de manera colaborativa, generando juntos valor de manera temprana, continua y constante, Inspeccionando y adaptándonos a las necesidades de nuestros clientes y teniendo presente siempre, la mejora continua. Así juntos evolucionaremos la cultura organizacional en pro de conseguir grandes resultados.

Gracias por tu tiempo.

Saludos,

 

 

Te gusto este Post?

Suscribete y cada vez que realice una publicación, te enviare una notificación a tu E-Mail.

 

2 respuesta a “Entendiendo lo que se creó, como consecuencia de dejarlos en el cajón del olvido”

  1. Hola Hernán, creo que tocas un punto importante. Tengo al menos dos comentarios.
    Por un lado, sin ser puristas en el idioma, me confunde el texto en cuanto a qué exactamente es lo que se ha olvidado. En la frase “noto con preocupación como ahora buscan la forma (algunos claro está), de querer ver por separado y unir algo que en esencia es una consecuencia del olvido, realizado en la otra” ¿qué debería entender? Haciendo un esfuerzo, el texto general del artículo da a entender que se nos han olvidado los principios ágiles y por lo tanto vemos como diferentes cosas que realmente son lo mismo: DevOps y agilismo. ¿Es correcto mi entendimieneto? Si es así, ¿a qué se refiere la expresión “la otra” en el texto citado?
    Por otro lado, creo que en este mundo tan grande siempre será muy complicado que cada persona en un equipo incorpore todas las habilidades tanto del agilismo como de devops. Esto suele desarrollarse por separado. Y esto tiene consecuencia en los líderes: o son ágiles o son DevOps. Y esto crea conflictos. En un mundo ideal, todos podemos ponernos de acuerdo a partir de principios y valores, pero en la práctica, la personalidad de líderes, asesores y consultores influye en cómo se toman las decisiones diarias y cómo suceden los procesos de cambio, y esa personalidad se ve influida por elementos tanto culturales como psico-sociales. Por ejemplo, es común en nuestra cultura organizacional que haya disputas sutiles entre líderes, asesores y consultores sobre quién tiene la razón cuando se tienen que tomar decisiones sobre cómo lograr un resultado (somos competitivos por naturaleza), y la razón siempre está contaminada de retórica cuando se habla de gestión, pues esta no es un ciencia exacta. La pregunta es: ¿se solucionan estos conflictos diciendo que DevOps y agilismo son lo mismo, o que al menos DevOps está embebido en el agilismo? ¿quién lo dice? ¿no puede haber un DevOps efectivo en una cultura no-ágil? y entre otras cosas ¿qué es una cultura no-ágil? ¿había culturas ágiles cuando ni siquiera se hablaba de agilismo? ¿cuánto agilismo es suficiente? ¿cuánto es necesario? ¿cómo se mide? ¿de qué sirve medir el agilismo?

    1. Hola Jaime, gracias por tu comentario; sin duda es un gran aporte. Te comento o mejor respondo a tus inquietudes. Primero que todo, si doy a entender que se nos han olvidado con el paso del tiempo ciertos valores agiles, pero no digo que DevOps y agile son lo mismo (mucho menos agilismo, eso si es definitivamente algo totalmente distinto); en mi humilde opinión, DevOps se crea, por olvidarnos precisamente de formar equipos cross-funcionales y multidisciplinarios; ahora esto no quiere decir como expresas en tu comentario que “cada persona en un equipo incorpore todas las habilidades tanto de agilismo como de DevOps”, por el contrario la idea es que en el equipo existan esas habilidades, mas no en todas las personas del equipo. por otro lado los proceso de cambio cuando no son gestionados correctamente, sucede exactamente lo que dices: “que haya disputas sutiles entre líderes, asesores y consultores sobre quién tiene la razón cuando se tienen que tomar decisiones sobre cómo lograr un resultado”, ahí el punto no es quien tiene la razón, sino como gestionamos correctamente el cambio, no podemos habilitar el paradigma necesario para evolucionar la cultura y así obtener mejores resultados en este mundo complejo. Tercero la pregunta no es si DevOps y agile son lo mismo (porque no lo son), pero si uno se creo (en este caso DevOps), precisamente por olvidarnos de formar equipos Multifuncinales como te dije en el párrafo anterior, por otro lado en lo personal, no creo que se logre implementar DevOps correctamente en un entorno NO ágil, dado que en el fondo la “cultura DevOps”, si la analizas es básicamente agile. para responderte otra pregunta que haces, sobre ¿que es una cultura no-ágil?, sin duda es una cultura no orientada a la entrega de valor constante y continua, al trabajo colaborativo, a la inspección y a la adaptación y sobre todo a la mejora continua. otra de tus preguntas es ¿había culturas ágiles cuando ni siquiera se hablaba de agilismo? y te puedo decir que si, porque todas las empresas son en cierto modo agiles ya que entregan valor, trabajan a su modo de forma colaborativa (aun existiendo silos), y de un modo u otro mejorar, sino no existiesen, por eso se habla de que la agilidad no se implementa, esta se habilita y se hace a nivel organizacional, para conectar silos, y promover una mirada End to End, que permita entregar valor de manera temprana, constante y continua, inspeccionar y adaptarse a los constantes cambios y promover una filosofía de mejora continua.¿cuánto agilismo es suficiente?de verdad que nunca es suficiente, porque el objetivo no es ágil,el objetivo es entregar cada vez de forma mas eficiente mas valor a los clientes. ¿cómo se mide?, se mide la adopción del mindset ágil, con respecto a sus valores y principios, y se mide la adopción de técnicas, herramientas y practicas, que apalanquen dicho mindset ¿de qué sirve medir el agilismo?, la verdad por si solo de nada, por eso medimos la adopción de la agilidad y del agilismo.

Deja un comentario

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