A lo largo de los anteriores posts hemos visto las motivaciones que tiene una empresa para adoptar el enfoque DevOps, comenzar con la transformación de la organización y las herramientas necesarias para llevar a cabo dicha transformación.
Ahora tenemos que dar un paso más, y afrontar cómo avanzar en dicha transformación. Es decir, quién o qué va a ser el catalizador del cambio. En este artículo voy a comentar, desde mi propia experiencia, una estrategia que he podido contrastar en la implantación de DevOps dentro de distintas organizaciones.
Existen distintas alternativas,
- Establecer un programa de cambio desde la dirección e imponerlo.
- Introducir un promotor del cambio en cada uno de los equipos.
- Contratar un equipo que se encargue de realizar la transformación
- etc.
Aunque algunas de estas estrategias podrían llegar a ser efectivas, no cuentan con el elemento fundamental: el cambio tiene que producirse desde dentro de la organización, desde los propios equipos que se van a ver afectados por estas iniciativas de cambio. Se tiene que lograr el convencimiento de las personas y eso es difícil si el cambio viene de fuera o impuesto.
En mi opinión la estrategia de éxito consiste en formar un equipo de DevOps que se encargue de iniciar el cambio, y que sirva de germen desde donde se extienda dicha transformación al resto de la organización. Es un proceso complejo que suele requerir la participación de un Agile Coach para que guíe cómo se debe hacer la transición, aportando conocimiento y liderazgo que oriente en la selección de las herramientas. Este Agile Coach será el perfil que se encargue de guiar a la empresa y equipo en el uso de los frameworks Agiles. Debe tener amplios conocimientos y experiencia práctica en el framework Scrum, lean thinking, kanban, etc.
A la vez, involucre a un Full-Stack Engineer para que trabaje mano a mano con los implicados, ayudándoles y formándoles como equipo. Un full stack engineer es aquel que es capaz de realizar todas las tareas dentro del flujo de valor tanto a nivel de desarrollo, como de testing, sistemas, automatización etc. No es un experto en todas las disciplinas pero es capaz de desenvolverse en todas ellas.
Esta idea tiene unas ventajas y unos riesgos que hay que tener muy claros para llegar a efectuar con éxito el proceso de cambio. Si queremos formar un equipo DevOps de forma efectiva, es necesario que este tenga unas características muy concretas que faciliten el éxito y se sigan además una serie de buenas prácticas para que el cambio se realice de forma correcta. No hay peor desperdicio que hacer lo “incorrecto” de forma eficiente.
- Una característica fundamental es que dicho equipo sea multifuncional en el sentido de que tiene ser totalmente capaz de realizar entrega de valor de manera autónoma e independiente. Debe contener personas de desarrollo, operaciones, calidad, testing, seguridad, negocio y en definitiva, de cualquier elemento dentro del proceso de entrega de valor existente en la empresa.
- El primer beneficio de unir en un mismo equipo a miembros de distintos departamentos de esta manera es que se “rompen” las barreras entre silos de información. Cuando juntas a estas personas se aprecia un aumento considerable de empatía entre ellos. Este cambio por sí mismo afecta muy positivamente al flujo de información. Para aumentar más este espíritu de equipo, es muy importante disponer de un espacio físico en el que este equipo pueda trabajar de manera conjunta. No siempre es posible, pero hay que tener en cuenta que la productividad con equipos trabajando juntos se dispara. De hecho es uno de los pilares básicos del agilismo.
Llegados a este punto, cabe aclarar que el hecho de que el equipo sea multifuncional, autónomo y auto-organizado no significa que todos deben saber de todo, pero sí que deberían existir determinadas características o habilidades en el equipo. Actualmente se habla de 3 tipos de perfiles:
PERFIL DESCRIPCIÓN I-shape Se corresponde con especialistas en determinadas tecnologías. Por ejemplo, DBA, webmaster, networking, programador java, etc. T-shape Especialista de una tecnología pero con amplios conocimientos en otras áreas. E-shape Especialista en varias tecnologías y conocimientos en varias áreas con gran capacidad de innovación.
En nuestro equipo DevOps evitaremos tener miembros con I-shape skills ya que conducen inevitablemente a la creación de cuellos de botella. Este efecto es el mismo que se produce a nivel de silos. Si tienes departamentos muy especializados, la información no fluye, es necesario mucho intercambio de trabajo con los consiguientes conflictos, esperas, etc.
- Por tanto, buscaremos miembros del equipo que sean generalistas y no especialistas. En este sentido, lo que buscamos es Full-stack engineer.
- Pero no solo necesitamos que el equipo tenga este tipo de capacitación técnica, sino que deben tener gran capacidad de liderazgo y comunicación. Este equipo va a ser el faro o la referencia para el resto de equipos y por tanto tienen que ser capaces de comunicar muy claramente su trabajo y ser capaces de convencer de los beneficios de los cambios que se introducen.
- Los miembros del equipo necesitan tener gran capacidad de aprendizaje e innovación ya que van a tener que idear y experimentar mucho.
Una vez que tenemos el equipo formado, éste debe seguir unas buenas prácticas de cara a asegurarnos de que la transformación se realiza adecuadamente.
El marco de trabajo SCRUM resulta muy beneficioso para estos equipos, ya que incorpora los elementos que favorecen la comunicación y trabajo en grupo. En particular son de especial relevancia:
- Mantener el equipo muy centrado en el objetivo a conseguir.
- Mediante los sprints se pueden conseguir quick-wins que fortalecen la confianza del equipo y sirven para mostrar las mejoras al resto de la organización. Por ejemplo, un sprint se puede centrar en montar la deployment pipeline en un servidor de integración continua. Otro objetivo de sprint podría ser implementar pruebas automáticas con BDD, otro crear un procedimiento de provisionamiento automático de entornos, etc.
- Daily Scrum meetings. El efecto de hacer reuniones diarias con miembros de los distintos silos de información es muy positivo para fomentar la comunicación y promover el sentimiento de equipo.
- Retrospectives. Se convierte en una reunión esencial para evaluar el resultado de los experimentos realizados.
A parte de estos elementos del framework SCRUM hay otras buenas prácticas como por ejemplo el “Pairing” a todos los niveles. De esta manera al trabajar en todas las tareas por parejas se consigue una revisión del trabajo continua a la vez que el conocimiento sobre las tareas específicas no recae en un único miembro del equipo.
El resultado es una mejora de la calidad espectacular aparte de la difusión del conocimiento dentro del equipo.
Otro elemento a realizar son los postmortems de los problemas producidos. De manera conjunta. Este tipo de reuniones son una gran fuente de aprendizaje para todos los miembros del equipo.
Por último y no menos importante, la calidad de lo que se realice por parte de este equipo debe ser excepcionalmente alta. Esto es necesario porque, el resultado de su trabajo va a ser el soporte para el resto de equipos. De hecho, una labor principal de este equipo será soporte al resto de los equipos a la hora de adoptar las mejoras y cambios que emanen de sus investigaciones.
Para poder llevar a cabo esta transformación es imprescindible que el equipo tenga la mayor libertad posible para poder realizar sus experimentos. Es decir, no deberá estar sujeto a procedimientos y políticas formales que puedan limitar su innovación, creatividad y capacidad de cambio. La única limitación será la de asegurar que no se interfiere de manera negativa con servicios en producción.
Por qué funciona esta estrategia
Antes de decidir formar este equipo DevOps deberíamos tener alguna garantía de que el resultado va a ser satisfactorio. Para ello consideremos algunos aspectos que nos generarán confianza:
- Se reduce la fricción entre departamentos mejorando mucho el trabajo en equipo.
- El famoso muro de la confusión desaparece, inicialmente para el equipo y a la larga para todos.
- Las mejoras técnicas se implementan en iteraciones cortas, lo que ayuda a evaluar el resultado, y tienen efectos prácticos inmediatos en el resto de equipos.
- Los tiempos de ciclo se reducen, fruto de la metodología y las mejoras técnicas.
- La motivación del equipo aumenta de manera importante como consecuencia de los resultados cuantitativos de su trabajo. Dicha motivación hace que la productividad del equipo aumente de manera notable.
Y lo primordial, estas mejoras van a dar confianza a la organización completa de que el cambio es posible y beneficioso. De esta manera el cambio se potencia y se retroalimenta.
Riesgos que comporta establecer un equipo DevOps
Como comentaba al principio, es importante tener muy claros los riesgos que tiene esta manera de implantar DevOps, para anticiparse y mitigarlos si se detectan. Enuncio los principales:
- El propio equipo DevOps se puede convertir en un nuevo silo de información aislado. Si esto sucede el trabajo de los demás equipos se bloquea, pues es el equipo DevOps quien debe dar el visto bueno al trabajo de los mismos. El resultado neto es que el tiempo de ciclo aumenta en vez de disminuir, al incluir un elemento más dentro del flujo de entrega de valor.
- Un equipo centrado en la calidad puede provocar que el trabajo que revisen nunca cumpla sus expectativas, lo que agrava el problema.
La estrategia a seguir en ambos casos es que el equipo DevOps no sea estático, sino que vayan rotando los perfiles. Así se consigue también que el conocimiento generado dentro del equipo se disemine por el resto de equipos. La entrada de gente nueva al equipo DevOps aporta ideas frescas y fomenta enormemente la innovación. Por otro lado, el incremento de plazos por este análisis de la calidad queda mitigado al ser los propios miembros salientes del equipo los que realizan los trabajos; además instruyen al resto de equipos con lo que la calidad va a estar al nivel requerido.
Hay que estar vigilante para corregir estos comportamientos en cuanto se detecten.
Finalizando
En este artículo he expuesto cómo comenzar la transición a DevOps a través de un equipo DevOps específico que se encargue de servir de catalizador para realizar dicha transformación.
He querido comentar lo que me ha funcionado a mí, con las empresas y personas que han participado en cada caso. No es la “bala de plata» que asegure el éxito. Mi consejo es que se experimente y se saquen las propias conclusiones.
El objetivo final de DevOps es provocar un cambio a lo largo de toda la organización, de manera que cuanta más gente de esa organización esté involucrada en el proceso mejor. Pero hay que buscar un equilibrio para que el proceso de cambio no provoque efectos nefastos en la organización mientras se va implementando la transformación.
Todo ello sabiendo que una iniciativa de este tipo, que tiene un coste, no debe considerarse como tal, sino como una inversión. Lo es por promover un cambio profundo y también por los retornos que va a generar a corto y medio plazo.
Por último, recordar que la implantación de DevOps no es un fin en sí mismo, sino una herramienta para mejorar la entrega de valor al cliente. Por tanto hay que evaluar de forma continua si nuestras iniciativas están cumpliendo su objetivo y corregir en caso de que no lo estén haciendo.
La experiencia de Xeridia apoyando a organizaciones de diversos sectores a formar equipos DevOps orientará a tu organización en la implantación de estas metodologías. Ponte en contacto con nosotros para saber cómo podemos ayudarte.
Emiliano Sutil es Project Manager en Xeridia
