Métricas en Agile: tu opinión es interesante, pero… tengo datos.

Si tuvieses datos para predecir cuál será el número ganador del gordo de Navidad, ¿seguirías escogiendo un número por lo bonito o feo que parece ser? En tus proyectos tienes datos para predecir y decidir cómo actuar en base a datos empíricos, huye de la intuición.

Todavía hoy en día se escuchan frases como “Eso de Scrum… ¿no te parece un invento de hippies?”. Estos comentarios suelen venir de personas acostumbradas a trabajar según los métodos tradicionales de construcción de software, a crear enormes documentos de especificaciones y planificaciones basadas en la intuición, acostumbradas a ver cómo esas planificaciones fracasan, a intentar equiparar la construcción de software con la construcción de un coche o de un edificio.

En un entorno caracterizado por una alta incertidumbre y cambios constantes e impredecibles, se debe utilizar un método empírico que, a través de entregas constantes, nos permita obtener la información y el conocimiento necesario para tomar decisiones. Ese conocimiento surge de la comparación entre una hipótesis y el resultado real obtenido tras la entrega.

Por tanto, la estrategia de producto a seguir en Agile es la de definir un MVP (Minimum Viable Product), comparar los resultados según las métricas estratégicas preestablecidas (KPI’s), con las hipótesis que hemos aplicado, corregirlas y volver a iterar con el aumento de conocimiento obtenido.

Tipos de métricas

Comparándolo con el enfoque de Scrum.org, las métricas estratégicas de las que hablamos anteriormente, podríamos llamarlas métricas directas, ya que tienen una aplicación directa sobre el valor que se desea generar: beneficio económico, beneficio social, mejora de la valoración de la compañía…

Estas métricas nos informan del estado de los objetivos estratégicos de la empresa, pero por si solas no nos dan suficiente información para saber en dónde debemos poner el foco para mejorarlas. Para ello, debemos apoyarnos en las métricas circunstanciales, que son métricas que sólo aportan valor mediante su agregación y balanceo.

Cuando comparamos las métricas directas con las circunstanciales provenientes de todos los aspectos posibles del proceso de construcción… ya no volverás llamar a Rappel para saber qué hacer.

Incluso podrás hacer mediciones de aspectos olvidados por las empresas, como son los beneficios que provocan las inversiones en formación, patrocinios o mejoras del ambiente laboral.

Vamos a nombrar algunas métricas agrupadas siguiendo el enfoque de Jason Tice:

1. Métricas sobre la salud del proceso. Enfocadas en evaluar las actividades necesarias para la entrega y los cambios que se producen durante todo el proceso de construcción: diagrama de flujo acumulado (nos permite ver y comparar de un vistazo el lead time, cycle time, WIP, tamaño del backlog,...), diagrama de control, flujo de la eficiencia, tiempo en progreso vs tiempo en proceso, tiempo de bloqueo por ítem...
2. Métricas sobre despliegues. Enfocadas en el proceso de entrega contínua: errores detectados y tiempo de resolución, tiempo de despliegue, ratio de despliegues con éxito, tiempo de estabilización de una release, tiempo entre despliegues con funcionalidad nueva, coste por release, ratio de adopción de una release / ratio de instalación
3. Métricas sobre el desarrollo del producto. Ayudan a medir el alineamiento entre las nuevas funcionalidades desarrolladas con las necesidades reales de los usuarios: valor de negocio entregado, NPS, burndown de riesgos, costes push/pull, pronóstico del producto, analítica de uso del usuario.
4. Métricas sobre el código. Para medir la calidad de la arquitectura y del código: índice de cobertura de test unitarios, tiempo necesario para crear el paquete, densidad de fallos, complejidad del código, ratio de indisponibilidad...
5. Métricas sobre el equipo. Métricas sobre factores humanos, ambiente de trabajo, compromiso del equipo: humor/felicidad/moralidad del equipo, Gallup Q12, log de aprendizaje, antigüedad del equipo, transparencia (acceso al cliente, a los datos, cómo se comparte el aprendizaje, éxitos y fracasos)...

Cómo aplicarlas

Depende mucho de la naturaleza del negocio. Los mismos números de una métrica pueden ser positivos en un negocio concreto y negativos en otro.

Algunos consejos:

• Escoge sólo aquellas métricas circunstanciales que te ayuden a conseguir una métrica directa. ¿Qué cambio esperas provocar? ¿Cómo podría ser malinterpretada o pervertida?
• Elige la frecuencia correcta con la que debes tomar los datos y la caducidad del experimento. ¿Cómo sabrás que ya no la necesitas?
• Úsalas siempre como tendencias, no como números aislados.
• Nunca uses una única métrica. El equipo la cumplirá desatendiendo otros aspectos del proyecto. Se crearán nuevos defectos que antes no ocurrían.
• Evita las métricas inútiles (vanity metrics): en general las que se enfocan a medir al individuo en lugar del equipo global (líneas de código por individuo, puntos individuales…) que hacen perder el foco sobre el valor real (número de nuevas funcionalidades desplegadas).
• Mantén una visión holística, revisando los datos en su conjunto.
• Ten en cuenta su contexto, no compares métricas aplicadas sobre tareas con las aplicadas sobre historias de usuario, épicas o bugs. Mucho menos hagas comparaciones entre equipos.
• Elige las métricas por consenso con el equipo, que no sean impuestas.
• Irradia la información con los stakeholders lo antes posible.

Desde Scrum.org proponen el Evidence-Based Management for Software Organizations (EBMgt), donde establecen un marco concreto de métricas que debe seguir una organización dedicada a ofrecer servicios a través del software.

Según su punto de vista, la supervivencia y éxito de una organización depende de 3 métricas directas o Key Value Measures (KVMs) que, a su vez, se apoyan en otras métricas circunstanciales:

1. Valor actual: Nos indica el valor actual de la organización en su mercado. Nos proporciona un contexto, pero no es válido para saber su valor en el futuro.
2. Ingresos por empleado: ingresos totales / número de empleados.
3. Product cost ratio: Gastos en mejoras (herramientas, coaching, eventos…).
4. Satisfacción de los empleados: % de empleados satisfechos/insatisfechos.
5. Satisfacción de los clientes: % de clientes satisfechos/insatisfechos.
6. Time to market: Tiempo que tarda la organización en lanzar nuevas funcionalidades, servicios y productos.
7. Frecuencia de despliegues: tiempo entre despliegues que aportan nuevas funcionalidades.
8. Estabilización de los despliegues: el uso de malas prácticas de desarrollo provoca la necesidad de tiempo para hacer correcciones, que además aumenta con el tiempo.
9. Cycle time: tiempo que transcurre hasta que se consigue entregar una funcionalidad al usuario final, incluye la estabilización.
10. Capacidad de innovación: Se considera un lujo en algunas organizaciones, pero es todo lo contrario. Mantener funcionalidades que no se usan obliga a dedicar gran parte del presupuesto en mantenerlas en lugar de buscar otras nuevas:
11. Índice de versiones instaladas: Cuántos usuarios usan la última versión frente a los que todavía usan las versiones en mantenimiento.
12. Índice de uso: % de uso que se hace de cada funcionalidad.
13. Ratio de innovación: % de presupuesto dedicado a innovar.
14. Errores: % de bugs en comparación con la versión anterior.

Hemos hecho un repaso sobre el tipo de métricas, consejos para aplicarlas e incluso una estrategia de aplicación concreta. Tu empresa está perfectamente diseñada para los resultados que está obteniendo.

Si quieres mejorarlos, no esperes que las cosas simplemente sucedan, tienes todo lo que necesitas para diseñar el sistema. ¡Fija tus objetivos y empieza a medir ya!