Gestión del cambio aplicado a DevOps: receta para el éxito

A lo largo de los distintos posts del blog, hemos ido viendo los distintos pasos y estrategias que podemos seguir para la implementación de un enfoque DevOps en nuestra organización. Hay que tener en cuenta que el cambio necesario dentro de la organización para poder implementar DevOps es bastante importante y en ningún caso, fácil.

A parte de la dificultad técnica que implica el cambio a DevOps, hay que tener en cuenta los cambios culturales y de mentalidad en lo que a las personas se refiere. Un cambio de esta envergadura se encontrará, sin lugar a duda, con una fuerte resistencia al cambio.

Siempre se ha asociado la resistencia al cambio como algo negativo, pero realmente no tiene por qué ser así. De hecho, la resistencia al cambio es el síntoma de que el cambio se está produciendo. Si no existiera esta resistencia, eso significaría realmente que no se está produciendo un cambio efectivo. Lo que tenemos que aprender es a saber gestionarlo.

Una de las razones por las que los cambios son difíciles y las personas se resisten a él, es porque nos obligan a salir de nuestra zona de confort y necesariamente nos ponen en una situación en la que pasamos de ser expertos en algo a novatos. A todos nos ha pasado cuando se ha introducido algún cambio en nuestras vidas o en nuestro trabajo y es algo normal.

A lo largo de este post, explicaremos una serie de modelos para saber gestionar el cambio y salir victorioso de ello.

Modelo de cambio de Satir: Hacia un nuevo Status Quo

Para conocer las fases por las que pasamos cuando nos enfrentamos a un cambio es muy interesante tener en cuenta el modelo de cambio de Satir que se representa normalmente con la gráfica:

Lo normal, cuando empezamos con un cambio, es pasar por una fase de resistencia y caos que nos hace pensar que, en la situación inicial, estábamos mejor que con el cambio que hemos hecho. Siendo consciente de esto, podemos progresar con el cambio y completar la transformación hasta llegar al nuevo status quo. Muchas iniciativas de cambio no tienen en cuenta esto y lo anulan antes de tiempo, por lo que nunca consiguen llegar a implementar dicho cambio y fracasan. A esta curva también se la llama la curva J por su forma.

Modelo de cambio de Kotter: Los pasos para el cambio

De acuerdo, vamos a intentar llegar a ese nuevo estatus quo a través de un cambio, pero ¿Cómo podemos implementarlo y gestionarlo de manera exitosa? En este punto yo utilizo, de manera no estricta, pero si a modo de referencia, el modelo de Kotter. Este modelo establece que para la gestión exitosa de un cambio se deben seguir ocho pasos como se puede ver en la siguiente figura:

No me voy a detener en describir el modelo de Kotter en detalle, pero quiero comentar como podemos usarlo para nuestra gestión del cambio.

Por ejemplo, en nuestro cambio para la implementación de DevOps podemos establecer el siguiente paralelismo:

Crear sentido de urgencia: Es importante que tengamos una razón real, no ficticia, ni impuesta para implementar un determinado cambio. En el post sobre los síntomas de que tu empresa necesita DevOps, describíamos algunas razones por las cuales nos interesaría implementar DevOps. Si a partir de la identificación de esos síntomas conseguimos establecer un sentido de urgencia conseguiremos comenzar con el cambio.
Crear coalición para liderar el cambio: En el post sobre la transición a DevOps a través de un equipo específico, lo que hacíamos realmente era establecer esta coalición que va a ser el catalizador del cambio. Hay que tener en cuenta que esta coalición debe contar con el patrocinio y apoyo de la dirección.
Crear una visión para el cambio y comunicar la visión: para estos dos puntos yo utilizo lo que se denomina gestión visual, usando radiadores de información, Canvas de cambio, Pizarras Kanban, tanto físicas como virtuales. Lo importante es fijar unos objetivos claros y utilizar las herramientas que maximicen su difusión.
Eliminar obstáculos: este punto, aunque no de manera estricta está relacionada con el post el éxito de la teoría de las limitaciones en DevOps, en el que buscamos siempre aquellos elementos que nos limitan en la consecución de nuestro objetivo con intención de gestionarlos.
Asegurar triunfos a corto plazo: en un entorno DevOps lo que buscaremos será realizar entregas lo más rápidas posible reduciendo el tiempo de ciclo. En esto nos puede ayudar lo descrito en el post sobre el uso de Small Batches, ya que al hacer entregas pequeñas estaremos asegurando éxitos muy rápidos.
Construir sobre el cambio: una vez que se han conseguido los pequeños éxitos y demostrado que vamos por buen camino, hay que profundizar en el cambio perfeccionándolo mediante un proceso iterativo. El uso de un framework como SCRUM nos puede ayudar en este punto.
Anclar el cambio en la cultura de la empresa: para que el cambio se consolide en la empresa, lo que tenemos que hacer es que el cambio se difunda y se interiorice por el resto de los equipos. Una de las técnicas de gran utilidad es la de “cross pollination”, mediante la rotación de perfiles en los equipos. Este último punto es realmente crucial ya que nos podemos encontrar con que al desaparecer el motivador del cambio (por ejemplo, un agile coach) se vuelva otra vez al origen. Es común observar que los cambios solo perduran mientras el patrocinador del cambio está presente desapareciendo cuando éste abandona el proyecto. No debemos subestimar la segunda ley de la termodinámica que nos asegura que el nivel de entropía o desorden tiende a aumentar con el tiempo. Es decir, solo mediante el trabajo de los agentes de cambio se está produciendo el cambio, al desaparecer esa fuerza, el sistema vuelve a su estado inicial. Por lo tanto, hay que ser conscientes que mantener el cambio siempre nos va a suponer esfuerzo y es ingenuo pensar que una vez conseguido se va a mantener indefinidamente.

Como vemos, de una manera más o menos formal podemos seguir el modelo de Kotter a la hora de gestionar el cambio necesario para la transformación de nuestra empresa. Si queremos hacer un seguimiento más detallado a bajo nivel de los cambios a implementar podemos seguir otro tipo de estrategias como Lean Change management, aunque esto lo dejo para un artículo posterior.

Emiliano Sutil es Project Manager en Xeridia