Agile Delivery: ¿Cómo podemos medir la productividad de nuestros equipos ágiles?

Una vez que se ponen en marcha un conjunto de equipos ágiles de desarrollo de software algún Gerente TI o un Delivery Manager suele hacer la siguiente pregunta: ¿Cómo podemos medir la productividad de los equipos ágiles? Y la respuesta rápida que surge es con la velocidad. Y aquí se puede complicar todo. Permítame aclarar que tanto las palabras productividad como velocidad son riesgosas de malas interpretaciones. Antes de usar la palabra productividad es preferible usar la palabra rendimiento o prestancia: es decir “performance”. Y cuando hablamos de velocidad, es preferible no pensar en velocidad como cantidad de entrega (cantidad de historias o cantidad de story points), sino como la rapidez de entrega (tiempo de entrega).

Métricas Agile

Un equipo ágil de alto rendimiento entrega software de calidad, funcionando en producción, de valor al cliente y a la compañía, en forma rápida. La velocidad está asociada a llegar rápido al cliente con funcionalidades de calidad y con valor. Aumentar la velocidad sirve para recibir feedback rápido del cliente, poder mejorar la propuesta de valor y adaptarse rápido. El rendimiento de un equipo, desde la perspectiva técnica de TI o DevOps, incluye esto. Bien, dicho esto… ¿Qué medimos? ¿Qué métricas de rendimiento podemos usar? 

Four Key Metrics o DORA Metrics

Nicole Forsgren, Jez Humble and Gene Kim nos ofrecen una buena respuesta en su libro Accelerate. Ofrecen una definición concreta y cuantificable del rendimiento de TI. Con cuatro métricas es posible comparar empíricamente, contrastar, clasificar y, posteriormente, mejorar el rendimiento de su equipo, de su tribu o área de desarrollo de software.

• Lead Time for Changes: el 'tiempo de entrega' (o Delibery Leat Time) es el tiempo que se tarda en pasar un ítem de requerimiento de cliente (historia de usuario) a inicio, hasta que está desarrollado y terminado (pasa el DoD). El reloj comienza, en un tablero kanban, cuando un elemento se mueve de la acumulación a cualquiera de los estados de "trabajo en progreso" y finaliza cuando el trabajo cumple con su definición interna de terminado DoD (por ejemplo, implementado y verificado en producción). El usado en DevOps es el Lead Time for Changes ("time it takes for work to be implemented, tested, and delivered"). El libro dice que se mide desde el primer commit de código hasta que se despliega en producción (“We measured product delivery lead time as the time it takes to go from code committed to code successfully running in production”). La parte de delivery del lead time —el tiempo que toma el trabajo ser implementado, probado y entregado—es más fácil medir.
• Deployment Frequency: la frecuencia de despliegue o Deployment Frequency es para medir la frecuencia con que se despliega en producción y conduce a que los lotes sean más pequeños (historias pequeñas), a hacer eficiente el pipeline de despliegue, mejorar el flujo de trabajo. Es probable que si la frecuencia aumenta entonces la performance también. 
• Mean Time to Restore (MTTR): (tiempo medio de restauración o Time to Restore Service) tiene más sentido medir la rapidez con que los equipos se recuperan de la falla que la frecuencia con la que ocurren. Un equipo performante es ágil para recuperarse de fallos. Aquí el reloj comienza cuando se produce una interrupción del servicio en producción y el reloj termina cuando se resuelve la interrupción. 
• Change Fail Percentage: (porcentaje de fallos de cambios o Change Failure Rate) una medida proxy de la calidad en todo el proceso es medir cuánto se falla en hacer cambios. Aquí se combinan dos contadores: uno para implementaciones y otro para fallas. El contador de KPI de Deployment Frequency se puede reutilizar para este caso. El segundo contador aumenta cada vez que se produce un fallo posterior (HOTFIX, OPCONS, roll back/forward, or patches, etc.). La tasa de fallas es la suma de fallas dividida por la suma de implementaciones en una ventana de tiempo dada. Mi consejo es que este KPI es reactivo, se correlaciona con la calidad pero a posteriori. Recomiendo usar además alguna métrica proactiva como: deuda técnica acumulada (Accumulated Technical Debt).

Por último, cabe aclarar que medir debería ser en función de mejorar y tener KPIs o métricas de rendimiento nos ayuda a eso, a mejorar. Sirve para mejorar el sistema de desarrollo de software o TI. Como dijo Jurgen Appelo: ¡Gestiona el Sistema y no a la gente! Por último hay que considerar que las métricas o KPIs se usan en función de metas, objetivos y propósitos. Los KPI solos y por si solos no sirve de mucho.

Referencias:

• The 4 KPIs Behind High-Performance IT May 31, 2018 By Adam Hawkins. 
• Accelerate – The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Gene Kim, Jez Humble, and Nicole Forsgren).
• Book Review: Accelerate.
• Measuring DevOps Success with Four Key Metrics.
• Article: ACCELERATE: SOFTWARE DELIVERY PERFORMANCE.
• Atlassian: DevOps metrics.
• Dora metrics.