Culture really matters - DevOps and Cloud days 2021
•Transferir como PPTX, PDF•
0 gostou•216 visualizações
El documento habla sobre la importancia de la cultura organizacional para lograr una transformación hacia DevOps. Señala que una cultura burocrática con silos y normas estrictas dificulta el cambio, mientras que una cultura de aprendizaje continuo, responsabilidad compartida y mejora consensuada entre equipos cross-funcionales favorece una transformación exitosa hacia prácticas ágiles y de entrega continua.
Recomendados
Mais conteúdo relacionado
Semelhante a Culture really matters - DevOps and Cloud days 2021
Semelhante a Culture really matters - DevOps and Cloud days 2021 (20)
Mais de Pablo Bouzada
Mais de Pablo Bouzada (11)
Culture really matters - DevOps and Cloud days 2021
- 1. CULTURE REALLY MATTERS Pablo Bouzada – Software Engineer Manager at Plain Concepts DEVOPS & CLOUD DAYS 2021
- 2. DEVOPS Es la combinación de cultura, prácticas y herramientas que aumenta la capacidad de una organización para entregar aplicaciones y servicios a alta velocidad.
- 3. —Random Company “Tenemos problemas de delivery… Vamos a crear un departamento de DEVOPS.”
- 4. —Random Company “Tenemos problemas de delivery… Vamos a crear un departamento de DEVOPS.”
- 5. —Random Company “Tenemos problemas de delivery… Vamos a crear un departamento de DEVOPS.”
- 6. PABLO BOUZADA Software Engineer Manager at Plain Concepts @pbousan https://pbousan.rocks
- 7. TIPOS DE CAMBIO TRANSICIÓN Un nuevo estado que soluciona los problemas del anterior. TRANSFORMACIÓN El nuevo estado es incierto y emerge de la visión, de la prueba y error, del aprendizaje continuo MEJORA El nuevo estado es una mejora del anterior. Nuevo estado Estado actual
- 8. PERO CAMBIAR NO ES FÁCIL ● Falta de esponsorización activa y visible. ● Insuficientes recursos (tiempo, material, formación, …) ● Falta de soporte de los equipos de proyecto. ● Resistencia de los managers y supervisores. ● Resistencia de los empleados.
- 9. RED FLAGS EN UNA TRANSFORMACIÓN ● El fallo no es una opción. ● Command and Control. ● Existencia de silos. ● Build/Deploy costoso y puntual. ● Normas estrictas y duraderas. ● Estandarización total. ● Talento externo.
- 10. ¿QUÉ PROPONEMOS? ● Aprendizaje continuo. ● Responsabilidad compartida. ● Equipos cross-funcionales. ● Integración y despliegues continuos. ● Mejora continua y consensuada. ● Arquitectura/Diseños de referencia. ● Potencial el talento interno. DE ESTO… … A ESTO ● El fallo no es una opción. ● Command and Control. ● Existencia de silos. ● Build/Deploy costoso y puntual. ● Normas estrictas y duraderas. ● Estandarización total. ● Talento externo.
- 11. CLARO QUE SÍ… ¿Y QUÉ MÁS?
- 12. ACCELERATE Estudio realizado del 2013 al 2017 mediante 23.000 entrevistas a más de 2.000 organizaciones.
- 14. WESTRUM ORGANIZATIONAL CULTURE BUREAUCRATIC (rule-oriented) Organizations protect departments. Those in the department want to maintain their “turf,” insist on their own rules, and generally do things by the book — their own book. GENERATIVE (performance-oriented) Organizations focus on the mission. How do we accomplish our goal? Everything is subordinated to good performance, to doing what we are supposed to do. PATHOLOGICAL (power-oriented) Organizations are characterized by large amounts of fear and threat. People often hoard information or withhold it for political reasons or distort it to make themselves look better.
- 15. LIDERAZGO TRANSFORMACIONAL ● Visión ● Comunicación que inspira ● Estímulo intelectual ● Liderazgo que da soporte ● Reconocimiento personal y colectivo
- 16. LA CULTURA LO CAMBIA TODO Una transformación requiere de un cambio en la organización
- 17. CREDITS: This presentation template was created by Slidesgo, including icons by Flaticon, and infographics & images by Freepik. THANKS! Do you have any questions? Networking Room 3 @pbousan https://pbousan.rocks @plainconcepts https://plainconcepts.com/
Notas do Editor
- 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.
- 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:
- 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”
- Resultado: eso de DEVOPS no funciona, volvamos a hacer las cosas como siempre.
- 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.
- 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.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.