En el post anterior, describíamos cómo aprender a gestionar el cambio en nuestra transformación hacia la aplicación de DevOps. Ese primer artículo, se centraba en describir los modelos Satir y Kotter, buscando aclarar los distintos pasos por los que pasan los procesos de cambio.
En este caso, vamos a tratar cómo efectuar los cambios concretos de manera efectiva a través del modelo llamado Lean Change Management. Este modelo de gestión de cambio lo describió Jason Little en su libro “Lean Change Managment: Innovative Practices For Managing Organizational Change” [1] y establece un framework para llevar a cabo de manera exitosa las iniciativas de cambio.
¿En qué consiste el modelo Lean Change Management?
La descripción de este modelo se puede ver en el siguiente diagrama:
Vamos a describir brevemente en qué consiste el modelo Lean Change Management y luego veremos cómo aplicarlo en algún caso concreto. En este artículo no se pretende hacer un análisis exhaustivo del mismo, pero sí resaltar los elementos importantes que nos sirvan para entenderlo:
- Insights o descubrimientos. Todo proceso de cambio comienza estableciendo la situación actual de partida del sistema. Lo que buscamos en esta etapa, es entender qué es realmente lo que está pasando dentro de la organización para tratar de identificar problemas o disfunciones, obteniendo todo el feedback que podamos. Para ello, podemos utilizar distintas técnicas como pueden ser reuniones informales, entrevistas, encuestas, retrospectivas, etc. Cualquier herramienta que utilicemos para conseguir este feedback se puede utilizar. Personalmente, encuentro muy útiles las reuniones informales con los equipos y a distintos niveles.
- Options u opciones: a partir de los descubrimientos obtenidos de la etapa anterior, podemos identificar las opciones que podremos implementar. Es importante evaluar en esta etapa el equilibrio coste-valor para ver la viabilidad de las distintas opciones identificadas.
- Experiments o Experimentos: En este punto es donde se diseñan los experimentos o cambios mínimos viables MVC. El MVC toma el nombre del concepto de Lean Startup MVP o producto mínimo viable. En este caso el MVC es el cambio más pequeño y menos intrusivo que tenemos que introducir para probar nuestras hipótesis. Esta manera de trabajar en base a testear o probar hipótesis es también típico del modelo Lean Startup en el que no se da nada por supuesto, sino que todo el conocimiento se fundamenta sobre hipótesis probadas o conocimiento accionable. Si nos fijamos bien, esta manera de actuar no es más que la implementación del método científico.
Una vez que hemos diseñado nuestros MVC entramos en la fase de ejecución del cambio, el cual se divide en 3 fases diferenciadas: preparación, introducción y revisión.
- Preparación: En la fase de preparación se diseña el experimento, y se utilizan distintos artefactos visuales que facilitarán la comunicación del experimento. Estos artefactos pueden ser una pizarra Kanban para gestionar las actividades o un Canvas de cambio.
- Introducción: Esta es el momento en el que se trabaja en el cambio. Normalmente se realizan reuniones en frente de la pizarra Kanban al estilo Scrum. Hay que tener en cuenta que durante estas reuniones pueden surgir nuevos Insights que alimentan el modelo y que puede hacer que sea necesario pivotar (cambiar de dirección) el cambio.
- Revisión: Según se va ejecutando el cambio, es necesario revisar cómo va funcionando de cara a validar las hipótesis del experimento. Es importante tener en cuenta las medidas asociadas al experimento y el tiempo para el que fue diseñado. En esta fase es donde revisamos si nuestro cambio ha tenido éxito o no.
Básicamente este es el ciclo básico que propone Lean Change Management para la implementación de los cambios. En el libro anteriormente mencionado de Jasson Little, del que recomiendo su lectura, se describe con mayor detalle este ciclo. En este punto quiero detenerme en el elemento básico del modelo: el Minimum Viable Change o MVC.
¿Qué es un Cambio Mínimo Viable o MVC?
Como comenté anteriormente, es el cambio más pequeño y menos intrusivo que tenemos que introducir para probar nuestras hipótesis. Es importante que sea pequeño para que el impacto global que tengamos no sea enorme, pero no debe ser tan insignificante que no tenga efecto alguno. Esto es difícil de evaluar y hay que tener en cuenta a quién y cómo va a afectar el cambio que introduzcamos. Muchas veces introducimos un cambio que es demasiado grande. Y fracasa. No porque fuera una mala idea, sino porque el impacto es muy importante y puede hacer que no pasemos de la fase de resistencia o caos (recordemos el Modelo Satir de gestión del cambio).
Para diseñar un buen MVC, hay que tener en cuenta que estos se componen de 4 componentes:
- Hipótesis: Las hipótesis que se establecen para el cambio que estamos considerando y que tenemos que validar.
- Medidas: Hay que establecer qué vamos a medir y cómo para validar las hipótesis del cambio. Estas medidas deben ser lo más concretas posibles y sin ambigüedades. Hay que tener en cuenta que, en base a estas medidas, estableceremos el éxito o no del cambio.
- Receptores del cambio: nuestro MVC tiene que definir claramente a quien va a afectar y, posteriormente, comunicárselo a los afectados. En caso contrario, la probabilidad de que el éxito funcione disminuye.
- Tiempo de aplicación del cambio: Hay que definir cuándo vamos a aplicar el cambio para que tenga éxito. En este punto, hay que tener en cuenta el modelo de Satir para no abandonar el cambio antes de tiempo.
Ejemplo de cambio usando Lean Change Management
Hasta aquí hemos descrito el modelo de Lean Change Management. Veamos ahora un escenario de uso del modelo.
Supongamos una organización que está teniendo problemas con los pases a producción (este es uno de los síntomas que indican que tu empresa necesita DevOps). Siguiendo el modelo, lo primero que tiene que hacer es identificar los descubrimientos o insights para evaluar cuál es la situación real actual. Para ello puede organizar reuniones con los departamentos implicados, entrevistarse con los responsables, organizar reuniones informales, lanzar encuestas, etc. A partir de los hallazgos resultantes de estas acciones se pueden obtener distintas opciones. Por ejemplo: empezar a usar un Kanban para los cambios en producción, usar Scrum, automatizar el proceso de despliegue, automatizar el proceso de validación, etc.
Una vez evaluadas las opciones según su coste e impacto se elige una y se diseña un MVC. Por ejemplo, se puede elegir automatizar el proceso de despliegue usando algún lenguaje diseñado para tal fin como puede ser Ansible, Puppet o Chef.
Podríamos definir el MVC de la siguiente manera:
» Establecemos la hipótesis: usando el despliegue automático en vez de manual, podemos reducir el tiempo de ciclo actual en un 50% eliminando totalmente los errores manuales. Este cambio afectará principalmente a los equipos de Desarrollo y Operaciones y será efectivo tras 4 sprints de 2 semanas (dos meses).»
A partir de aquí se trabajará en el cambio siguiendo el ciclo prepare-introduce-review.
Conclusiones finales sobre Gestión del cambio
A lo largo de los 2 artículos destinados a la gestión del cambio, hemos visto cómo aplicar los modelos de Satir, Kotter y Lean Change Management. Hay otros modelos que pueden ser efectivos. Lo importante es que a la hora introducir cambios en una organización estos deben hacerse de una manera coherente y racional. Muchas iniciativas de cambio fallan por no tener en cuenta este tipo de elementos.
En Xeridia hemos observado cómo los clientes que adoptan marcos de trabajo ágiles y vencen la resistencia al cambio en su organización logran una gran ventaja competitiva frente a los demás, mejorando de forma sustancial en todos sus procesos. Conoce más sobre nuestros marcos de trabajo ágiles y empieza a gestionar el cambio en tu organización ahora.
Emiliano Sutil es Project Manager en Xeridia
[1] Little, J. (2014). Lean Change Management: Innovative Practices for Managing Organizational Change.
