El caso del rechazo a medir
Con el tiempo me he dado cuenta que hay varias formas de seguir los indicadores ágiles de un equipo. Como digo muchas veces, cada equipo es un mundo y los indicadores en agile también. Por eso he decidido dividir este tema en tres post diferentes. Según mi experiencia, he bautizado como los indicadores ágiles de largo, medio y corto plazo.
Ya se trabaje en Scrum o Kanban, de forma cíclica, llega la hora de medir si el equipo responde a sus propias acciones. Estas acciones acostumbran a llegar desde las retrospectivas, con la finalidad de mejorar algún aspecto de nuestra efectividad.
¿Por qué los he llamado indicadores ágiles “De largo plazo”?
En mi caso, para un equipo en el que ver los indicadores cada sprint causaba un poco de estrés, decidí acabar mostrándolos sólo cuando podían causar impacto. Realmente, si tengo que ser sincera, como veía que iban mejorando creo que tardé 6 meses. Está claro que si hubiera visto que algo iba mal, hubiera reaccionado antes. Sabía que ellos no los controlaban :-). Además aproveché una retrospectiva para ello. El equipo estaba comentando que este evento no servía para mucho, así que decidí que era el momento para enseñarles que todo lo que hablaban en ellas tenía una repercusión en lo que medíamos. Esto se llama “tener un as bajo la manga” 😉
Situación
Equipo dedicado a servicios, sin foco a un proyecto concreto, valorando las tareas por horas. Se cogen tareas por valor a las horas disponibles, sin guardar ningún porcentaje para incidencias (ya lo habíamos probado pero ese espacio se convertía en un cajón de sastre).
Como veis en el siguiente gráfico, recuperando datos por sprint, se ve que no todos son buenos. Pero a la larga, la tendencia sube para las tareas realizadas y baja para las incidencias.
¿Con qué datos trabajo en estos casos?
Datos base:
- Tareas iniciales del sprint
- Tareas que entran al sprint cuando éste ya está empezado
- Incidencias que entran al sprint cuando éste ya está empezado: con esto sabemos que si cada vez entran menos incidencias urgentes, la calidad funcional está mejorando. Con este valor medimos la eficacia del equipo.
- Tareas entregadas (pasadas al Done)
- Horas disponibles del equipo al empezar el sprint
- Total de horas de todas las tareas cogidas para el sprint
- Total de horas de todas las tareas completadas en el sprint
Generación de porcentajes y su uso:
- % de tareas entregadas (Eficiencia en tareas por sprint): El tamaño del equipo era cambiante. Los miembros iban entrando y saliendo por colaboraciones con otros equipos. Por ese motivo trabajar con un porcentaje nos daba un valor más o menos estable sin tener en cuenta el número de personas que formaba el equipo de desarrollo.
- % acumulado de tareas entregadas (Eficiencia media de todos los sprints): Este porcentaje es la media de todos los % de tareas entregadas en otros sprints. Al final es muy probable que siempre se llegue a un valor constante…y así ¡conseguimos que el PO tuviera una idea concreta de qué cantidad de trabajo se podía entregar en un sprint!
- el % de incidencias en issues que entran al sprint cuando éste ya ha empezado (Eficacia): Si el % de tipos de tareas que entran al sprint cuando éste ya ha empezado NO es prácticamente todo de incidencias, deberíamos buscar la causa. Si es única y exclusivamente el PO quien decide qué entra para modificar el sprint, estaría bien hablar con él y buscar el origen del problema juntos.
- % de compromiso: El total de las horas de las tareas cogidas en el sprint dividido por las horas disponibles del equipo. Es decir, cuánto de conservador o arriesgado es el equipo a coger tareas valoradas, sabiendo las horas de las que disponen.
- % completado: El total de las horas de las tareas entregadas dividido por el total de las horas de las tareas cogidas en el sprint.
- % completado por capacidad (Eficiencia en horas): El total de las horas de las tareas entregadas, dividido por las horas que el equipo tiene disponibles. Es decir, la eficiencia del equipo.
Conclusión sobre indicadores ágiles a largo plazo
Es posible que para algunos de vosotros todo esto sea un poco surrealista, pero a nosotros nos funcionaba. Se suele decir que no importa cómo se aplique el método ágil. Lo importante es adaptarlo a cada equipo, siempre se mantenga su esencia y la filosofía de su cultura.
Ahora nos hemos pasado a Kanban y medimos otras cosas que os comentaré en un nuevo post 🙂
Lo más importante es que con estos datos logramos llegar a unos valores constantes, que eran útiles para el PO, ya que aplicándolos a futuro podría prever con mucha exactitud qué tareas iban a estar listas en cada sprint.
Espero que a los que os encontréis en una situación similar os pueda servir. Ya sabéis que estoy encantada que dejéis vuestras opiniones y que aprendamos juntos.