Value Stream Management: Midiendo resultados

Value Stream Management: Midiendo resultados por Gabriel Casarini y co-autor Alonso Álvarez En el artículo anterior de esta serie se presentaron las métricas de Flow Framework para medir el flujo de trabajo de los value streams. Estas métricas muestran diferentes parámetros de la actividad de los equipos, como por el ejemplo: la carga de trabajo, la velocidad y la eficiencia de flujo. Nuestro objetivo con este artículo es ver de qué forma podemos establecer una correspondencia entre esas métricas y los resultados de negocio.

¿Cómo medimos el valor en la producción de software?

Cuando hablamos de valor nos referimos al valor de negocio que se genera al implementar un feature, una épica, corregir un defecto, etc. El valor se manifiesta de diferentes formas: ahorro de costes, mayores beneficios, mayor retención de clientes, nuevas oportunidades, mayor satisfacción de los usuarios. En algunos casos es relativamente simple evaluar el impacto de las actividades y los equipos son capaces de cuantificarlo: “La migración de la aplicación a la nube genera un ahorro de 10.000 € mensuales”. Pero en general, medir el valor y el impacto es una tarea compleja. En todo caso podemos establecer cierta correlación en el tiempo entre la actividad del equipo y los resultados obtenidos. Por cierto, el beneficio no siempre es monetario. Por ejemplo: el valor de un spike es el aprendizaje obtenido para tomar decisiones técnicas, el valor de pagar la deuda reside es una mejora en la agilidad de los equipos, etc.

Hay muchas formas de aproximar la medición del valor. El marco de Evidence-Based Management (EBM), desarrollado por Ken Schwaber y Scrum.org, propone medir, gestionar y aumentar el valor entregado por los equipos actuando en 4 áreas: Current Value, Time to Market, Ability to Innovate y Unrealized Value. Además, establece métricas, como los ingresos por empleado, grado de satisfacción del cliente, satisfacción del equipo, tendencia en corrección de defectos, etc. Es un enfoque empírico especialmente orientado al desarrollo de software.

Midiendo los resultados de negocio en Flow Framework

Flow Framework va en la misma línea que EBM y establece 4 métricas para medir los resultados de un value stream: Business Value, Business Cost, Quality y Happiness. Veamos los detalles:

Business Value

Es el beneficio generado por el value stream, en términos de negocio. Si se trata de un producto para usuarios finales, podríamos medir el valor mirando los ingresos recurrentes, la cantidad mensual de usuarios activos o la tasa de renovación. Buscamos respuestas a cuestiones como esta: “¿Existe alguna correlación entre la reducción del Flow Time del 1er trimestre con el aumento de los ingresos en el 2do trimestre?” Los valores de esta métrica deberían obtenerse directamente del equipo de finanzas o marketing y es importante que los datos estén desagregados para cada value stream. A veces es difícil cuantificar el valor. Por ejemplo: ¿Cuál es el beneficio económico que generan los componentes de una plataforma de software que es utilizada internamente? ¿Y el valor generado por una aplicación de facturación? En estos casos deberíamos usar métricas indirectas.

Value Stream Cost

Se refiere al coste total que genera la entrega de valor. Incluye todos los costes directos y compartidos. Por ejemplo: costes de personal interno y externo, gastos en licencias, pagos por infraestructuras, etc. Haciendo una correlación de esta métrica con el histórico de la Flow Efficiency podríamos obtener respuestas a esto: “La mejora en la eficiencia de flujo lograda en el 3er trimestre, ¿se tradujo en una reducción de costes en el 4to trimestre?” En su libro “Project to Product”, Mik Kersten comenta que, si cada equipo esté dedicado a un único value stream, contabilizar los costos es simple. La incapacidad de poder cuantificar el costo generado por cada value stream es un ejemplo de por qué un enfoque orientado a proyectos no es escalable. Si no es posible medir de forma fiable los costos de un value stream, tampoco se puede determinar el beneficio creado por cada producto. Esta falta de visibilidad reduce la agilidad para gestionar las inversiones en innovación de forma más dinámica. 

Value Stream Quality

Es la calidad del producto entregado por el value stream, desde el punto de vista del cliente. Existe cierta correlación entre las métricas de calidad y el desempeño y productividad de los equipos y, por extensión, de la organización. Podemos medir, por ejemplo, la tasa de incidencias. También hay métricas que pueden actuar como leading indicators de la calidad. Por ejemplo: la edad de los ítems, es decir, el tiempo que transcurre desde que entran al flujo. La métrica de Value Stream Quality analizada conjuntamente con el histórico de la distribución de los ítems ayudaría a responder a: “El tiempo invertido en pagar la deuda técnica durante el 1er trimestre, ¿ha reducido los defectos del siguiente release?” Como ocurría con el coste, es importante tener métricas de calidad independientes en cada flujo. De esta manera, si, por ejemplo, se decide acelerar el release de determinada funcionalidad a costa de sacrificar la calidad, esto aparecería reflejado en las métricas—de la misma forma que el impacto económico se reflejaría en la métrica de valor.

Happiness

Esta métrica busca medir la temperatura y salud del equipo en cada value stream. Las personas motivas y comprometidas son más productivas y creativas. Algunas organizaciones utilizan el Employee Net Promoter Score (eNPS). Nuevamente, establecer correlaciones entre esta métrica y otras nos ayudaría a responder a: “¿Existe alguna correlación entre la reducción de la carga (Flow Load) del equipo en el trimestre anterior y el nivel de eNPS que obtuvimos la semana pasada?” La salud de los equipos tiene muchas dimensiones y los indicadores nunca deberían reemplazar completamente las conversaciones personales.

Flow Framework permite relacionar las métricas y los resultados

El flujo de trabajo por un value stream debe maximizar la entrega de valor, minimizar los tiempos de entrega y lograr que el proceso sea tan fluido—es decir, predecible—como sea posible. A veces estos objetivos son conflictivos, sobre todo cuando hay dependencias entre los equipos. En el desarrollo de software, la entrega de valor se produce al momento del release de la solución técnica—cuando ponemos el entregable en manos del cliente. Construir las soluciones de forma incremental y hacer releases frecuentes no solo reduce riesgos y acelera la entrega de valor—y la obtención de los beneficios—sino que permite influir sobre el proceso de desarrollo mirando el impacto directo que produce sobre los resultados de negocio. La capacidad de medir resultados directamente permite a los equipos achicar la brecha que mantienen con las áreas de negocio y hablar su mismo idioma. Hemos visto que Flow Framework define métricas a nivel de los value streams que están enfocadas al cliente y a la entrega de valor de negocio. Esto permite abordar el desarrollo de software desde una óptica más orientada a productos. Al conectar el trabajo de los equipos y las herramientas que usan para planificar, crear, entregar y dar soporte, es posible medir el flujo de valor, de principio a fin, en tiempo real. Y así, hacer ajustes de forma más pragmática con la vista puesta en los resultados obtenidos. Parte 1: Midiendo la entrega de valor