El momento de la transformación

La transformación agile tendrá éxito si todas las personas están abiertas al cambio.
transformacion agile

Como agente del cambio te enfrentarás a diferentes momentos de transformacion agile de equipos diferentes. Unos querrán adoptar el cambio rápido, otros se unirán porque ven al vecino que le funciona, otros se mantendrán expectantes… pero, ¿y si no quieren el cambio?

Hoy te voy a contar un caso con un final inesperado, y con el que te llevarás un aprendizaje importante. Imagina que tienes que comenzar a acompañar un equipo que lleva un tiempo haciendo “su” Scrum (aquí tienes una entrada con algunos de los efectos que provoca). Tienen un evento quincenal para revisar un panel en Jira y una retrospectiva para ver cómo había ido el sprint y qué pueden mejorar. Con esto ellos ya se ven ágiles frente al resto de equipos tradicionales de su entorno. 

Para empezar les explicamos el marco de trabajo y que el equipo entienda el propósito de cada evento, rol y artefacto. Dentro de un equipo, cuando se enteran que van a iniciar la transformación, la incertidumbre es máxima y conocer el marco ayuda a reducirla. Para ti, como agente transformador, te ayuda a ir despejando inquietudes del camino y hacer que afloren las necesidades del equipo. Ya te hablamos hace unas semanas de la resistencia al cambio.

Dirigimos nuestro apoyo a comenzar a utilizar framework: preparar los trabajos para la planificación de la iteración, diseñar una buena review donde se refleje el incremento de producto entregado y se obtenga feedback del usuario, realizar unas retrospectivas que sirvan al equipo para impulsar y asentar sus ciclos de mejora continua…

En este caso, formamos a una persona del equipo como Scrum Master. Se presentó de forma voluntaria, lo que hace que parta con un alto grado de motivación. Como componente del equipo, además, conoce a sus compañeras y compañeros. Pero necesita de un acompañamiento dedicado para su rol. Lo mismo ocurre con el Product Owner. Es una persona del equipo, dedicada durante mucho tiempo a la gestión y organización tradicional, aunque había descubierto algunas prácticas agile y las había puesto en marcha en el equipo. 

Según pasan los sprints, el equipo va interiorizando el marco y sus principios. Aumenta la comunicación entre ellos, se lanzan eventos para traspaso de conocimientos entre ellos y así distribuir mejor la carga de trabajo, aflora el trabajo no planificado que se está atendiendo por otros canales e impacta en los resultados de los sprints… vamos, un estándar, sin sorpresas.

Frente a todos estos cambios y mejoras, el Product Owner continúa con reticencias en el proceso. Para intentar solventar la situación se intensifica el acompañamiento con él. Durante semanas se trabaja la gestión del backlog, refinamientos y definición de trabajos con el objetivo de conseguir resultados que le hagan confiar en el modelo. Pero la distancia con el cambio del resto del equipo cada vez es más grande y se convierte en un problema. 

El equipo no quiere dejar el marco de trabajo, pero el Product Owner no quiere unirse. Después de un último intento de ofrecerle más ayuda, se toma la decisión: el Product Owner cambia a un equipo con una metodología más tradicional. Para ocupar el rol se escoge a una persona del equipo de desarrollo. No es una decisión fácil y conlleva muchos riesgos. Pero funcionó. 

Con este caso quiero que entiendas que hay veces que no podemos conseguir unir a la transformación agile a todas las personas. Y, aunque no es una decisión fácil, el resultado a día de hoy es que el equipo continúa con su transformación y el nuevo Product Owner tiene asumido su rol a la perfección. Mientras la otra persona continúa trabajando de la forma en la que se siente más cómodo. 

Para la transformación agile necesitamos que las personas estén en un momento de apertura. Si no es así, cuesta mucho esfuerzo lograr esa apertura y, como en este ejemplo, puede que no podamos hacer esa transformación. Pero no es un fracaso. Simplemente no se dan las condiciones en ese momento, en el futuro quién sabe…

Tabla de contenidos

Comparte:

Más artículos

lean-kanban

Lean Kanban ¿qué es?

El Toyota Production System, data de los años 50 del siglo pasado. Es un complejo conjunto de principios y prácticas que han llevado a Toyota

Devops ¿qué es?

DevOps surge de la necesidad de mejorar el proceso de gestión de las operaciones en los equipos de desarrollo de software. Está basado en un

valor en empresa

Define qué significa VALOR en tu empresa con estas claves

En términos de agilidad, lo primero que se nos viene a la mente es “aporte de valor”. Es una expresión muy manida, con frases como “Con Scrum maximizamos el aporte de valor” o “Primero abordamos los elementos que aporten más valor”.

Suscríbete y mantente al día de las novedades

¿Alguna duda?

¡Reserva 30 minutos con uno de nuestros expertos y soluciónala!