Deducir causas con los indicadores o encontrar con ellos objetivos de equipo
En una entrada anterior os hablé ya de algunos indicadores, (ir a los de largo plazo) que bauticé así porque a mí me había servido ir recopilando datos en los sprints y sacar tendencias. Resulta útil en equipos a los que sentir que su trabajo se mide en cada sprint les puede causar estrés.
¿Cómo surgieron las de medio plazo?
En equipo, y con la ayuda de un agile coach, establecimos aquellos puntos que nos ayudarían a medir nuestra evolución. Más allá de estar pendientes de los resultados de cada sprint e intentar mejorar para el ciclo siguiente, el objetivo era medir algunas casuísticas que nos podrían dar información a medio plazo.
Nota: para estas mediciones da igual el método ágil que usemos para trabajar, Scrum o Kanban.
¿Cuáles son estos indicadores?
Son seis:
-
la velocidad del equipo
Medimos el lead-time, el cycle-time y como no, el throughput (tareas terminadas) mensualmente. Lo hacemos únicamente de las historias de usuario con la intención de encontrar la velocidad de entrega de valor y poder predecir entregas de funcionalidades futuras.
-
el tipo de tareas con las que trabajamos
Se trata de intentar trabajar con tipos de tareas como historias de usuario, tareas (técnicas), incidencias, spikes (tareas de investigación)…. con el fin de evitar crear otras como por ejemplo análisis funcional, gestión, revisión…que quizá son más propias de proyectos tradicionales. Para explicarme, nosotros entendemos que el análisis funcional desaparece vs las historias de usuario, la gestión desaparece vs la comunicación y la revisión vs las sub-tareas de testing dentro de la historia de usuario.
En este caso también revisamos los datos mensualmente.
-
la calidad técnica
Para ello medimos el coverage de las aplicaciones. También se pueden seguir los bugs, por ejemplo. La calidad técnica también es una métrica mensual y comparamos su evolución con el valor del mes anterior.
-
la calidad funcional
En este punto medimos las incidencias creadas vs las incidencias resueltas. También mensualmente.
-
la satisfacción del cliente
La forma más fácil de medir la satisfacción de alguien es a través de una encuesta. La encuesta se pasa cada tres meses y comparamos el resultado con la encuesta anterior.
-
la felicidad del equipo
También lo medimos con una encuesta, y también cada tres meses.
En la calidad funcional, por ahora no diferenciamos entre incidencia detectadas por el cliente y detectadas por el equipo, pero es una idea que ha surgido en la última retrospectiva y vamos a empezar a trabajar en ello.
El análisis de los indicadores
Disminuye el throughput y luego se mantiene
Al principio cuando todavía no controlábamos mucho las historias de usuario las hacíamos demasiado pequeñas, incluso para cosas que realmente no entregaban valor como ente unitario. Así que rectificamos y parece que estamos encontrando la medida adecuada.
Aumenta el lead-time y el cycle-time
El momento del gráfico en el que también aumenta el cycle-time, hubo un problema técnico que no nos dejaba desarrollar, y eso hizo que se vieran afectadas ambas mediciones.
Cuando se detecta que sólo aumenta el lead-time, hemos deducido que puede deberse a varias situaciones:
- porque cualquier idea que se nos ocurre la ponemos en el backlog como posible historia de usuario
- porque refinamos las épicas mucho antes de lo que necesitamos
Ambos casos estarían justificados viendo en el gráfico de dedicación, que efectivamente hay más historias en el backlog.
Aumenta la calidad técnica
Esta es fácil :-), el equipo revisa constantemente la calidad antes de subir algo a producción.
Disminuye la calidad funcional
Coincidió este aumento de incidencias con la presentación del producto al cliente y su puesta en marcha. Tras esta visión, ya se han analizado las causas y estamos tomando medidas para reducirlas en la próxima presentación. Acciones como revisar más los criterios de aceptación, realizar historias de usuario más claras cuando se trata de temas con muchas casuística, diferencias las incidencias técnicas de las que realmente son consultas del usuario por desconocimiento…
Aumenta la satisfacción del cliente y la felicidad del equipo
En este caso sólo puedo decir una cosa: que me siento orgullosa del equipo por estar asumiendo el mindset agile tan bien. Su implicación día a día se ha visto reflejada directamente en la satisfacción del cliente.
Casos hipotéticos
Si aumenta el throughput y disminuye la felicidad del equipo…
Habría que investigar qué punto de la felicidad del equipo es el dañado. Quizá pueda ser que el equipo esté haciendo horas extra, que hayan tenido alguna época de conflictos entre ellos por presión a entregas…
Mmmm ahora mismo no se me ocurre ninguno más…¿y a vosotros? Si se os ocurre algo no dudéis en añadir un comentario.
Otros usos
Analizando los datos, también se pueden usar estas métricas para ponernos objetivos de equipo, por ejemplo:
- Aumentar la satisfacción del cliente en X puntos más para la siguiente encuesta
- Hacer crecer el coverage de la aplicación hasta X% en un tiempo Y
- Aumentar la felicidad del equipo en un punto concreto para la siguiente encuesta
- Focalizarnos en resolver incidencias durante X sprints.
- etc, etc, etc, aquí la imaginación juega un gran papel.
Otro uso más; si por ejemplo estos indicadores se sacan para distintos equipos y vemos que todos coinciden en algo, quizá tenemos un problema a nivel organización. Por ejemplo:
- Todos tienen una puntuación muy baja en felicidad de equipo, a nivel técnico…puede ser que haya problemas con las subidas a producción desde un departamento común a todos.
- Todos tienen un coverage muy bajo…es posible que por mentalidad no se esté dando importancia a la calidad técnica.
- …
Una vez más, espero que esta información os sirva de ayuda, y como he dicho antes, comentad todo lo que se os ocurra, sin filtros ;-P