Culture really matters - DevOps and Cloud days 2021

Notas del editor

• #3: Cuando hablamos de DEVOPS no todos tenemos en mente lo mismo. No hay una definición canónica al respecto, pero podríamos decir que es una combinación de cultura, practices y herramientas que aumenta la capacidad de una organización para entregar aplicaicones y/o servicios a alta velocidad. El problema es que algunas organizaciones se quedan sólo con la parte final, que hay herramientas que les permiten entregar a más velocidad. También que se ve DevOps como LA SOLUCIÓN a los problemas de delivery.
• #4: Cuando una empresa tiene problemas con su delivery, que pueden ser aspectos desde la infraestructura a la calidad de lo que entrega, en los últimos años es común escuchar algo así: Vamos a crear un departamento de DEVOPS. Juntemos a los desarrolladores con los de IT para mejorar nuestras releases. Montaremos unos pipelines de continuous integration y continuous deployment, con tests automáticos y esas cosas. Cogemos algún post de internet de los de “Migramos a AWS y DevOps en 2 fines de semana” y ya lo tenemos. Seguro que es fácil. Pasan 2 semanas, 4 semanas, 2 meses… y nada cambia realmente. Sí, se prueban algunas herramientas, las que más hype hayan generado a los devs o a los Its. Se hacen reuniones, algunos opinan. Se copian algunos manuales de alguna empresa como Netflix o Spotify. Pero esos procesos no los puede seguir nadie porque:
• #5: IT no deja que el equipo de backend toque el Jenkins, que lo rompen. El DBA está muy ocupado manteniendo el entorno de PRO para crear entornos de tests. Los frontends no hacen tests porque el framework “de la casa” se pega con Cypress. Además, nadie puede contratar un servicio de cloud sin la aprobación del director financiero… Que está hasta las narices de las peticiones de “LOS INFORMÁTICOS”
• #6: Resultado: eso de DEVOPS no funciona, volvamos a hacer las cosas como siempre.
• #7: Mi nombre es Pablo Bouzada, y soy Software Engineer Manager en Plain Concepts. En los últimos años me encontré varias veces en situaciones como esta. Una empresa se embarca en un cambio de este tipo y se da de bruces contra su propia realidad. La realidad en la que infravaloran el calado que va a tener este cambio. DevOps no es un producto que puedes instalar, entender y hacer funcionar de un día para otro. No es un framework o una serie de procesos en los que te formas, los sigues y ya está. Tener muchos servicios pequeños y desplegarlos con dolor un par de veces al mes tampoco es DevOps. DevOps requiere un cambio más grande que esto. Implica cambiar la forma en la que se despliega, el quién y el cómo. Cambiar cómo se desarrolla. Cómo se gestionan la infraestructura. Cómo se monitoriza… Son muchos cambios.
• #8: Y no todos los cambios son iguales, tenemos los cambios sencillos, que simplemente mejoran el estado anterior cambiando las herramientas que usamos. Tenemos los cambios que necesitan que se diseñe e implemente un nuevo estado que solucione los problemas del actual. Esto requiere que se gestione la transición entre estados, normalmente desmantelando el antiguo y pasando al nuevo. Y tenemos el más difícil, suele ocurrir cuando el mercado nos obliga a adaptarnos a una nueva realidad y requiere un cambio fundamental en la estrategia y las operaciones. El nuevo estado al que queremos llegar, es desconocido, al menos para quien está haciendo el cambio, puede que no para su competencia que te obliga a cambiar, y emerge de una visión de un estado mejor. Hace falta un cambio en la mentalidad (mindset), en los principios de la organización, en los comportamientos, los procesos. En definitiva, en la cultura de la organización.
• #9: Pero cambiar así no es fácil. Según Prosci, que es una empresa que se dedica desde hace muchos años a esto de la gestión del cambio, los fallos más comunes cuando se aborda una transformación son: Falta de esponsorización activa y visible. Insuficientes recursos (tiempo, material, formación, …) Falta de soporte de los equipos de proyecto. Los equipos que deberían liderar esta iniciativa están dedicados a otros temas. Se pierde el momento. Resistencia de los managers y supervisores. Porque ven en peligro su posición, su rol o el poder que tienen en la organización. Resistencia de los empleados. Porque cambiar, cuesta y no nos gusta.
• #10: Cuando planteamos un cambio de este tipo, una transformación, me suelo fijar en la existencia de una serie de comportamientos: El fallo no es una opción. Command and Control. Existencia de silos (throw over the wall). Build/Deploy costoso y puntual. Normas estrictas y duraderas. Estandarización total. Talento externo (equipo interno desactualizado).
• #11: Es difícil encontrar alguno de estos comportamientos de manera aislada. Normalmente son varios o todos, y cuanto más haya y más arraigados estén, más difícil será la transformación. Cuando encontramos alguno de estos comportamientos, planteamos pasar de esto… a esto - Aprendizaje continuo. - Responsabilidad compartida. - Equipos cross-funcionales. - Integración y despliegues continuos. - Mejora continua y consensuada. - Arquitectura/Diseños de referencia. Pocos estándares. Potencial el talento interno. (upskilling con colaboraciones puntuales). Lo que pedimos es que ocurra un cambio en la cultura de la empresa.
• #12: Os podéis imaginar que cuando pedimos esto no se suele acoger con los brazos abiertos. Es entonces cuando sacamos la artillería… los datos.
• #13: Desde el año 2013 se realiza un estudio que mide el rendimiento de equipos que desarrollan y entregan software y cuyo primer resultado fue el fantástico libro Accelerate.
• #14: Este estudio se sigue realizando ahora bajo el paraguas del programa DORA, los que sois padres seguro que os suena esta otra Dora… Lo que descubrieron los autores originales y que corroboraron los siguientes informes es que en los equipos de alto rendimiento, que son los que sacan el máximo partido a las prácticas técnicas relacionadas con DevOps, existen dos cosas fundamentales: una cultura basada en la colaboración y un liderazgo transformacional.
• #16: La investigación muestra que el liderazgo eficaz tiene un impacto significativo y medible en los resultados de la entrega de software. Y que se basa en 5 dimensiones: Visión: Entiende claramente hacia dónde se dirigen su equipo y la organización, y dónde quieren que esté el equipo. Comunicación inspiradora: dice cosas positivas sobre el equipo; dice cosas que hacen que los empleados se sientan orgullosos de ser parte de su organización; anima a las personas a ver las condiciones cambiantes como situaciones llenas de oportunidades. Estimulación intelectual: desafía a los miembros del equipo a pensar en viejos problemas de nuevas formas. Permite que el equipo cuestione el status quo. Liderazgo de apoyo: se tiene en cuenta las necesidades personales de los demás; ve que se tengan debidamente en cuenta los intereses de los miembros del equipo. Reconocimiento personal: elogia a los miembros del equipo cuando hacen un trabajo mejor que el promedio; reconoce la mejora en la calidad del trabajo de los miembros del equipo; felicita personalmente a los miembros del equipo cuando hacen un trabajo sobresaliente.
• #17: En definitive. Es necesaria la transformación de la organización para que realmente se saque partido del cambio tecnológico que implica DevOps, si no, se quedará en pequeños cambios que acabarán desapareciendo si no queda nadie empujando con todas sus fuerzas.