Niveles de la transformación

Si acompañas a un equipo en su transformación estarás al tanto de todo lo que ocurre en él y las prácticas ágiles que ha incorporado. Sin embargo, cuando el número de equipos aumenta se complica la forma de controlar el nivel de adopción de la transformación y cómo detectar las necesidades de los equipos.

Según crece el negocio de las empresas, es normal que se contrate a más personas para ayudar a sostener ese crecimiento. Ese aumento de personal hace que la empresa pase a estar formada por un número cada vez mayor de equipos que se dedican a hacer crecer la cartera de servicios o productos para generar más negocio.

La transformación ágil puede empezar como un piloto en un equipo de la empresa. Se aplica un marco de trabajo y se estudia el impacto en el producto y los usuarios. Ese impacto hace de motor de transformación para que otros equipos se sumen al proceso.
En otros casos, la transformación se inicia desde la dirección que quiere incorporar el marco ágil en su cadena de producto o servicio. Incluso tenemos la acción combinada: organizaciones que comienzan con un piloto y que los resultados hacen que la dirección apueste por la transformación de la organización completa.

Como agente del cambio, según avanza la transformación y va sumando equipos al cambio, es difícil tener información acerca del estado del proceso en cada uno de los equipos. Una solución podría ser contratar a un agente del cambio por cada equipo, pero supone un coste muy elevado para organizaciones grandes. Otra solución podría ser, no comenzar a transformar un equipo hasta que no se haya completado la transformación del equipo anterior. Pero esto puede suponer un largo periodo de tiempo. Seguramente te enfrentarás a acompañar varios equipos en diferentes etapas de su proceso de transformación.

Para evitar la pérdida de información y poder visualizarla de forma fácil, te recomendamos que establezcas una serie de niveles de transformación. En cada nivel, el equipo tiene una serie de prácticas ágiles que incorporar para poder pasar al siguiente. Cada práctica te recomendamos que seas capaz de evaluarla con una métrica: satisfacción del usuario, lead time, cycle time, … De esa forma podrás analizar de forma objetiva si has conseguido el efecto deseado con la práctica.

Con estos niveles te será más fácil conocer el estado de la transformación en los equipos y dirigir los siguientes pasos del acompañamiento. Pero no estarás sólo en esta tarea. Te deberás apoyar en los roles clave del proceso: Scrum Master y Product Onwer, o Service Delivery Manager y Service Request Manager en Kanban. Cada uno de estos roles tiene un área de influencia sobre el equipo y el producto o servicio, que podrá usar para conseguir adoptar las prácticas de cada nivel. Incluso el equipo de desarrollo, conociendo las prácticas que incluyen cada uno de los niveles, puede ser un apoyo importante para el acompañamiento.

El nivel debería subir con el transcurso del tiempo, pero puede ocurrir que se retroceda en el proceso. Lo importante es tener la información lo antes posible para poder reaccionar de manera temprana. Tendrás que hablar con el equipo al completo para indagar qué está haciendo que la transformación se haya detenido. Por esto es necesario que la información de estos niveles se actualice de manera constante. Además de hacer dueños del proceso de actualización a los equipos, necesitarán de herramientas de automatización y visualización. Incluso los niveles tendrán que ser actualizados con el paso del tiempo, para incorporar nuevos niveles y/o nuevas prácticas que sigan impulsando la transformación.

La información que obtengas del histórico de cambios en las prácticas de los equipos te pueden servir para aproximar los tiempos de cambio de nivel, identificar los cuellos de botella que paran la transformación, identificar patrones entre los equipos, … Incluso puedes unirlas a las estadísticas de los usuarios del producto o servicio para ver el impacto de la transformación.

También te puede interesar.

Multiplica los resultados de tu Sprint Planning

Hoy es día de Sprint Planning. Miras hacia tu equipo y… sólo ves pacas de paja rodar de un lado a otro. ¿Qué ha pasado con tus compañeros? ¿Dónde se esconderán? ¡Te han dejado solo! Te traigo 5 consejos para multiplicar los resultados de tu Sprint Planning.

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

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.

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.

Mi estrategia de Onboarding como Scrum Master

Me incorporo a un equipo como Scrum Master, ¿¿por dónde empiezo??

Estoy seguro de que esta pregunta ha pasado por la cabeza de más de uno y de una cuando se ha enfrentado al reto de comenzar a trabajar en una nueva empresa o con un nuevo equipo. En este post quiero compartir una estrategia que yo he utilizado y me ha sido útil para abordar el proceso de onboarding.

En que punto del proceso consideramos el Producto como Entregable

Escoger dentro de nuestro proceso de generación de producto entregable el punto adecuado, puede ser muy complejo cuando dependemos de terceros.

Por dónde empezar como Product Owner que viene de Tecnología

Estás dando tus primeros pasos como Product Owner, tras haber pasado años diseñando y desarrollando software. Te enfrentas a varios dilemas.

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.

El uso de las Métricas para saber nuestro nivel de Incertidumbre

Scrum nos ayuda a manejar la incertidumbre. Pero ¿cómo sabemos que lo estamos consiguiendo? ¿Qué métricas pueden ayudarnos a confirmar que tenemos bajo control la incertidumbre?

¿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.

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