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á más 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 más 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 aún 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,


También te puede interesar Leer



SUSCRÍBETE A MI BLOG

Y cada vez que realice una nueva publicación, recíbela al instante.


    
Suscríbete al Blog
Y entérate cada vez que realice una nueva publicación.
Suscribirse
Te puedes dar de baja cuando lo desees!
close-link
A %d blogueros les gusta esto: