A menudo, los árboles no permiten ver el bosque. El día a día, con su realidad tozuda de reuniones y entregas, pueden cegar el desarrollo de software. Las métricas suelen centrarse en aspectos relacionados con la mecánica de los equipos y de los ciclos de entrega: WIP, WIA, velocidad, cycle time o delivery rate, pero lo verdaderamente importante no es lo que ocurre dentro de los equipos sino lo que ocurre con los equipos, y entre ellos y sus usuarios finales. La mejora continua siempre debe orientarse a la entrega real de valor no al valor supuesto o estimado.
La mejora continua de cada equipo particular de forma sostenida no es fácil, es necesario la confianza a largo plazo en el marco de trabajo para reconocer la validez y aprovechar las oportunidades. El Agile Manifesto, nos dice: A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.
La eficacia hace referencia al efecto perseguido mientras que la eficiencia guarda relación con el uso que se haga de los medios. Por lo tanto, las métricas deben centrarse en lograr de forma efectiva los fines, dado que la eficiencia o funcionamiento internos de los equipos son medios para la consecución del fin primero.
Un conjunto de métricas de equipo que validen las sensaciones con datos y pueda tratar cada iteración como una mejora a lo largo del tiempo en los valores orientados a la relación entre el producto y los usuarios que se midan, sirve de respaldo y de evidencia para la toma de decisiones.
Dado que una transformación agile parte del compromiso en la autogestión de los equipos, un marco de liderazgo o de toma de decisiones basado en ellas nace de abajo a arriba, con datos agregados que son aprovechados en los distintos ámbitos de decisión. Siendo los equipos autoorganizados, las métricas deben nacer y ser gestionadas desde ellos.
La mejora continua es un proceso mensurable que requiere de métricas para poder valorar el avance. Las métricas y las mediciones son polémicas porque existe el temor de que se mida para fomentar una competición más que una mejora de la entrega de valor sustancial.
Centrándose en lo urgente en vez de en lo importante, los equipos pierden oportunidades de mejorar y progresar como unidad individual o integrados dentro de un esquema corporativo. Debe garantizarse que exista un ecosistema que sea proclive al desarrollo de este esquema de desarrollo. El liderazgo se debe ejercer de forma estructurada y a largo plazo, con objetivos y, cómo no, también con métricas que permitan tomar conciencia de los avances u obstáculos.
Los equipos deben centrarse en la esencia de agile, que no es otra cosa que el proceso continuo de inspección y adaptación en pos de la entrega de valor mediante un flujo iterativo de mejora de la eficacia.
Medir la velocidad de los equipos y contar el volumen de tickets total que pasan por el flujo de trabajo es lo peor que le ha pasado al desarrollo de software desde que waterfall demostró su incapacidad para adaptarse a la incertidumbre, dado que perpetúa su esencia y lo esconde tras el humo y espejos de algo que solo es agile formalmente.
Lo único que se debe medir es cómo y cuánto los usuarios desean utilizar y utilizan el software entregado y qué impedimentos se interponen. El resto de métricas se supedita a las anteriores, cada KPI debe favorecerlas.
Evidence-based management (EBM) procura establecer decisiones basándose en las mejores evidencias disponibles. Se establecen áreas de medición y métricas apropiadas en cada una de ellas: Unrealized Value, Current Value, Ability to Innovate y Time to Market.
Simplificando, las más relevantes para un caso general y que cubren esencialmente el espectro de medición, serían:
Ingresos
Es lo que permite que la rueda siga girando. Estos ingresos pueden ser directos a través de usuarios finales o puede suponer un ahorro y, por lo tanto, un flujo constante de financiación atendiendo a su pertinencia.
Usuarios activos
Es lo que permite determinar si el software se está utilizando y, por lo tanto, determinar si el incremento de valor que entrega cada equipo representa un beneficio real para los usuarios o si debemos revisar el flujo de inspección y adaptación.
Net Promoter Score (NPS)
Esta métrica representa la valoración de los usuarios respecto al software entregado. Mide la experiencia de los clientes y preside el crecimiento de negocio. Se divide en promotores, pasivos y detractores. Restando el porcentaje de detractores del porcentaje de promotores da como resultado el NPS.
Market Share
Representa el porcentaje de mercado controlado por el producto y, por lo tanto, la cuota potencial que podría alcanzarse de enfocarse en las necesidades del usuario.
Tickets de soporte abiertos
Representan el número de incidencia o solicitudes de soporte abiertos por los usuarios por unidad de tiempo. Los tickets de soporte pueden representar un bug, un procedimiento mal explicado en la documentación o un mal uso del software, por lo tanto, el objetivo no es eliminarnos sino mantenerlos lo más bajo posible.
On-Product Index
Fundamentalmente, es el tiempo que un equipo dedica a trabajar en valor para el producto.
Deuda técnica
Representa el esfuerzo adicional en los equipos producto de haber tomado atajos en el desarrollo del producto que resulta en la necesidad de dedicar esfuerzo posterior para subsanarlo, restando capacidad de trabajo al equipo.
Rendimiento
Representa el comportamiento del software respecto al tiempo o capacidad como tiempos de respuesta o proceso y volumen.
Existe una tendencia a obsesionarse por métricas de optimización de proceso que satisfagan la ley de Little o un flujo con una cadencia consistente con un Lead Time reducido, y tendemos a olvidar que las métricas relevantes son aquellas relacionadas con el negocio y con los usuarios.
Los esfuerzos de los equipos deben orientarse siempre en dos aspectos, a dar valor real a los usuarios y en eliminar o mitigar todo aquello que entorpece su entregar. Para lograrlo, los equipos deben enfocarse en buenas prácticas, eliminación de deuda técnica y enfocarse en valor real, eliminado esfuerzos de valor percibido pero no no efectivo en el desarrollo del producto. Esto se logra mediante un flujo de experimentación y validación de hipótesis dentro de los sprints que permite recibir información contra la propuesta inicial, inspeccionarla, adaptarla y utilizar el resultado como nuevo punto de partida sobre el que establecer la siguiente propuesta en base a las hipótesis planteadas.
Unos equipos concienciados de la necesidad de centrarse en estos aspectos, mejorarán la entrega de valor y comprenderán que el resto de acciones son medios orientados a la satisfacción del fin que no es otro que la verdadera entrega de valor siempre con el esfuerzo puesto en los usuarios finales del software.
Imagen: Unplash | @austindistel
Deja un comentario