Un equipo que aspira a la mejora continua necesita basarse en algunos datos además de resultados. Cuando un equipo usa métricas en beneficio propio, sin el propósito de moldear comportamientos, puede lograr evolucionar.
Respecto al uso de métricas, el pensamiento necesita actuar así: si no medimos, no sabemos dónde estamos. Si medimos mal, creemos estar en un lugar, cuando, en realidad, estamos en otro. Si la métrica es irrelevante no tiene sentido medir.
Cuidado: ¿Cómo pueden las métricas moldear el comportamiento de un equipo?
Si solo calcula la velocidad de entrega del producto, podrá obtener como resultado un equipo muy eficiente, aunque con un producto de calidad ínfima. Es como si el equipo fuese un niño que se envalentona cuando ve que el agua retrocede hacia el mar, y corre hacia ella. En breve, el agua volverá con mucha más fuerza, como una ola, y lo tumbará. Así, sucede con los errores: surgen como una ola y le dan un verdadero susto en el equipo.
Por otro lado, tener un equipo eficiente y de calidad, pero que entrega un producto sin valor, es como hundirse en el Titanic al son de violín y saboreando un té inglés. En un escenario así, surge una duda: ¿qué debemos medir?
En 2014, el socio fundador de Knowledge21, Rodrigo de Toledo, escribió el artículo ¿Hasta dónde llega la agilidad? En el mismo se presentaron los cuatro Dominios de la Agilidad (Negocio, Organización, Técnico y Cultural), y cómo podemos usarlos para realizar el análisis de equipos y empresas, además de definir cuáles son los próximos pasos de la Transformación Digital. Además, podemos usar los cuatro dominios para mantener el equilibrio de las métricas que un Equipo Ágil debe tener siempre presentes.
Ejemplo de Métricas en las 4 Áreas del Dominio de las Métricas Ágiles
Eficacia (Negocio)
En este dominio, las métricas están directamente asociadas a los problemas del negocio. Si el equipo se crea para resolver problemas, estas métricas traducen en números el propósito del Equipo Ágil y miden la eficacia de la solución que se construye.
En Métodos Ágiles, los requisitos del producto normalmente descritos en el formato de Historias del Usuario no deben tratarse como certezas absolutas que tenemos sobre la solución que estamos desarrollando. En realidad, los requisitos son solo hipótesis que pueden o no resolver el problema.
En cada lanzamiento del producto debemos evaluar la eficacia de la entrega. Si utiliza el formato de Historias del Usuario, estos cálculos ayudan a medir si se alcanzó el Para.
Historial del Usuario
Deseo <funcionalidad, hipótesis de solución del problema>
Para < problema que debe resolverse >
Ejemplo: Yo, cliente regular del sitio X, deseo una lista de recomendaciones de libros para facilitar mi proceso de elección.
Podemos afirmar que la funcionalidad fue eficaz si aumentó la cantidad de ventas de los libros que estaban en la lista de recomendaciones de los clientes regulares del sitio. Objectives and Key Results (OKR) es una buena técnica para definir no solo un cálculo, sino también la meta que deseamos alcanzar.
Ejemplos: Atención al público, Comportamiento del Usuario, Churn, Crecimiento en el Mercado, Coste de Adquisición, Coste de Demora (Cost of Delay), Coste de Funcionamiento, Facturación, Cuota de Mercado, Cuota de los Canales de Contacto, Fitness For Purpose Score (F4P), Lifetime Value (LTV), Payback, Cálculos del Pirata (Adquisición, Activación, Retención, Ingresos y Referencia), Net Promoter Score (NPS), Rendimiento de la Inversión (RoI), Sentimiento Social, Usuarios activos, Ventas, etc.
Eficiencia (Organizativa)
Las métricas del Dominio Eficiencia están asociados al rendimiento del trabajo del equipo con relación a la entrega del producto. Sirven para la previsibilidad en el trabajo, identificar cuellos de botella del proceso y apoyar prácticas de colaboración internas y externas para el equipo.
Las métricas Kanban suelen ofrecer índices de eficiencia correctos. Estas métricas pueden obtenerse a través del análisis de Historias del Usuario, mapeados por grado de importancia en un determinado cuadro de actividades (Cuadro Kanban, Cuadro Scrum, Task Board, Cuadro del Equipo, como prefiera llamarlo).
Ejemplos: Lead Time, Tiempos de Ciclo, Tiempo de Ejecución (Touch Time), Tiempo de Espera (Waiting Time), Trabajo en curso (Work in Progress, WIP), Flujo.
Calidad (Técnica)
Estas métricas miden la calidad técnica del producto que se está construyendo e indican el valor de las deudas técnicas que creamos a lo largo del desarrollo.
Ejemplos:
La calidad técnica de un producto puede evaluarse a través de lo siguiente:
– Fallos —la cantidad de fallos (bugs) y la cantidad de usuarios afectados por los mismos;
– Código —si el software tiene cobertura de tests automatizados, cual es la complejidad del código fuente o la duplicación de este código;
– Rendimiento y seguridad, es decir, por la carga de acceso al sistema, la cantidad de intrusiones y usuarios simultáneos, además del consumo de CPU, memoria y HD.
Atmósfera (Cultural)
En este dominio, las métricas miden la satisfacción de los participantes con relación a su trabajo en un equipo u organización. El número medido es subjetivo y solo sirve para el propio equipo. No puede utilizarse para ningún tipo de comparación entre equipos. Las métricas son tan particulares que el intercambio de participantes probablemente las alterará para bien o para mal.
En algunos casos, utilizamos el Happiness Radar para evaluar algunos aspectos importantes del equipo, tales como procesos, herramientas y prácticas usadas en el trabajo, en la relación con los colegas, en la satisfacción personal de pertenecer al equipo, en la satisfacción en la realización del trabajo, etc. Otra técnica interesante es el Squad Health Check Model, usado por Spotify. Hay otras técnicas como el NPS de Time, Acciones para el Camino del Nirvana, entre otras.
Conclusión
En el texto, tenemos varios ejemplos de métricas para cada uno de los cuadrantes (dominios) y el equilibrio entre los mismos debe considerarse esencial. Sin embargo, piense muy bien cuáles desea mantener en cada área. Si el equipo abarca mucho, no presta atención a nada. Opte solo por una cantidad suficiente para que el equipo no se pierda. Las métricas deben ser pocas, simples de medir, fáciles de comprender, relevantes para el camino que el equipo está emprendiendo, y el trabajo del equipo debe poder influir en las mismas.
