El momento de la transformación

Como agente del cambio te enfrentarás a transformaciones 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 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 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…

También te puede interesar.

Sprint Review: más allá de la demo

La Sprint Review es el evento de Scrum donde se muestra el resultado del sprint. Una buena review te ayudará en la estrategia de producto.

Definition of Ready y Definition of Done

¿Qué necesitas para poder comenzar una tarea? ¿Cuándo podemos dar una tarea por terminada? Para resolver estas dudas, en este vídeo te traemos el Definition of Ready y el Definition of Done

Cómo facilito una retrospectiva si no soy Scrum Master

Una buena retrospectiva da la oportunidad al equipo de analizar su funcionamiento y establecer mejoras. Te dejamos consejos para facilitarla.

Cómo convivir con las incidencias en un Equipo Scrum

En los Equipos Scrum que desarrollan nuevo software y mantienen el ya existente, es muy habitual tener que lidiar con incidencias provocadas por el software en producción. Su gestión es complicada ya que interrumpen directamente nuestro plan para el sprint, y al producto ya priorizado en el Product Backlog.

¿Es conveniente tener un Equipo Scrum en exclusiva para Incidencias?

En tus Equipos Scrum os encontráis en una situación en la que la cantidad de incidencias que hay que atender os penalizan demasiado, o la deuda técnica acumulada aumenta en exceso la complejidad de cualquier evolución en software.

Apoya a tu equipo entendiendo qué le ocurre

La transparencia es uno de los pilares de Scrum. Con ella conseguimos hacer visible lo que ocurre dentro del producto, equipo, personas, … para hacer inspección y adaptación. ¿Cómo podemos saber qué ocurre en el equipo para poder apoyarle?

El Product Owner y su relación con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders.

Aprendiendo en un Equipo Scrum

El conocimiento compartido potencia a tu equipo. Aquí descubrirás cómo identificar las áreas de conocimiento y favorecer su aprendizaje continuo

Beneficios de la automatización en los equipo Scrum

La automatización, cada vez más, forma parte del desarrollo del software. ¿Qué beneficios tiene para los equipos Scrum?

Scrum para disipar incertidumbre

Scrum es un marco que te puede servir para hacer lo mismo de siempre a trocitos. Sin embargo, puedes utilizar Scrum de manera inteligente y sacarle toda su potencia. ¿Cómo? Orientándolo a generar certezas sobre tu producto o tu mercado.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies