Scrum Mastery

Después del primer post sobre métricas ágiles, donde se exponía como medir conceptos como el Average Customer Lead Time, Cycle Time y WIP a través de su relación con la Ley de Little, quedó pendiente una explicación de métricas de producto a nivel circunstancial y cómo agregarlas a alto nivel

El problema de la Pizza

Imaginemos que nos asociamos con nuestros mejores amigos para abrir una Pizzeria. Por supuesto, para poder elaborar un plan de negocio y seguirlo, necesitaremos de una serie de métricas que nos indiquen como va el negocio. La más importante son los ingresos y los beneficios. Pero más allá, ¿Que podríamos medir?

Podemos imaginarnos muchas cosas que nuestro negocio nos permite medir, como el número de Pizzas entregadas en cada viaje en moto, las pizzas más rentables, el número de repartidores, el número de reclamaciones, el valor medio de un pedido, etc…

Métricas directas vs Métricas circunstanciales

En realidad, todas estas métricas se pueden agrupar en dos tipos de métricas: directas y circunstanciales. Las directas son las que tienen una aplicación directa sobre el valor que generamos, mientras que las circunstanciales nos dan información que debe ser agregada antes de poder usarla para obtener valor.

En el caso de nuestra Pizzeria, el número de pedidos entregados por viaje en moto de nuestro repartidor podría ser una buena métrica, hasta que nos preguntamos: ¿Realmente son rentables estos viajes? Si estamos regalanado nuestras Pizzas por debajo de precio, cada viaje en moto no sólo no agrega valor a nuestro negocio sino que genera valor negativo: Nos cuesta dinero.

En una gran Telco, el Management de area decidió implementar un bonus para aquellos que encontraran más bugs dentro de la aplicación. El resultado fue espectacular, el número de bugs reportados se incrementó en más del 100%. Sin embargo, un análisis posterior reveló que la mayoría de estos bugs eran descripciones similares o iguales a problemas ya conocidos dentro de la aplicación

¿Cómo medimos entonces el valor?

En primer lugar, hay que tener claro que significa valor para la organización. Esta es simple: Valor es la capacidad de generar beneficio económico. Para organizaciones sin ánimo de lucro es: Capacidad de generar un beneficio para la sociedad. Ojo, beneficio económico o beneficio social no sólamnete son euros contantes y sonantes, sino que pueden incluir, por ejemplo, una mejora en la valoración de la compañía.

Una definición clara de valor es parte de una estrategia de negocio, apoyado en una visión y misión clara. Lamentablemente, muchas organizaciones no tienen claro estos puntos antes de lanzar nuevos productos o compañías al mercado.

Metricas circunstanciales -> Métricas directas

Volvamos al ejemplo de la Pizza. Si medir el número de pedidos por viaje no tiene sentido sin considerar el beneficio de cada pedido, ¿Cómo podemos transformar esas métricas circunstanciales en métricas directas? Mediante la agregación y el balanceo. En el caso de nuestra Pizzería, tendremos que buscar la manera de agregar diferentes métricas para obtener una que nos permita saber si somos rentables o no.

Métricas directas en el desarrollo de Software

Cuando desarrollamos un producto de Software nos encontramos en una situación aún más complicada. No sabemos que parte de nuestro Software y de la inversión que hacemos influye más en la generación de valor para nuestro producto o compañía.

No he conocido a ninguna compañía que mida el efecto que un training de Scrum como el que yo mismo hago en su creación de valor. O de una Hackaton. La mayoría lo hacen siguiendo una filosofía de Cargo Cult. Lo hacen porque otros lo hacen. No son capaces de relacionarlo con su propia creación de valor.

La mayoría de las métricas que podemos obtener en el desarrollo de Software son puramente circunstanciales.

Aquellas métricas más directas no sirven para ajustar la estrategia. Sin embargo, podemos usar las métricas cricunstanciales para medir directamente el valor utilizando el framework de Evidence Based-Management.

Evidence-based Management

EBMgt surge por parte de Scrum.org como una respuesta a la pobre medición y seguimiento que hacen las organizaciones que usan Scrum de su valor. La idea es prestada de la Medicina Basada en la Evidencia (MBE). Para poder tomar una decisión, es necesario tener pruebas que den soporte a esa decisión, evitando las decisiones basadas en el conocimiento común o las corazonadas.

Evidence-based Management propone una serie de tres métricas directas desagregadas en 12 métricas circunstanciales obtenidas de la información de la compañía: Valor actual, Time to Market y Capacidad de innovación.

Valor actual

El valor actual se obtiene de la agregacion de cuatro métricas:

• Ingresos por empleado: Se obtiene midiendo los ingresos brutos/número de empleados. Nos indica una rentabilidad bruta por empleado.
• Satisfacción de los empleados: Porcentaje de empleados que se califican a sí mismos como “Satisfechos” o “Muy satisfechos”.
• Satisfacción de los clientes: % de clientes que se consideran “satisfechos” o “muy satisfechos”. Se puede sustituir por el Net Promoter Score.
• Product cost Ratio: Coste de la inversión de mejoras (training, herramientas, espacios de trabajo) comparado con el cambio en ingresos brutos

Si introducimos mejoras en el proceso de despliegue fomentando DevOps y formamos al equipo para que use

Scrum pero nuestros ingresos brutos se mantienen o descienden, entonces sabremos que no estamos enfocandonos en el área de la compañía que requiere atención. Al igual que la medicina, hay que dar un tiempo para ver como evoluciona el paciente antes de tomar otras acciones.

Time to Market

El tiempo que tardamos en llegar al mercado es una métrica fundamental de negocio, ya que nos permite medir el coste de oportunidad perdido usando el Cost of Delay correspondiente a un producto o una característica existente de nuestro producto. En EBMgt lo medimos en base a tres métricas circunstanciales:

• Frecuencia de Release: El tiempo que pasa entre release funcionales, no de corrección de bugs o mantenimiento.
• Estabilización de Release: Tiempo que pasa entre que se completa el código y se lanza realmente a los clientes.
• Cycle time: El tiempo que necesitamos para entregar una pequeña funcionalidad nueva (no bugs) al cliente

Es importante reseñar que, si al igual que en el caso anterior, fomentamos DevOps para reducir nuestro Time to Market, si tenemos gran deuda técnica, no haremos más que pagar esa deuda técnica y nuestros valores de esta métrica permaneceran estáticos. Para eso tenemos la siguiente.

Capacidad de innovación

Nuestra última métrica directa es una medición de nuestra capacidad para innovar. Para ello utilizamos cinco métricas circunstaciales que nos daran una idea de cómo de bien lo hacemos en este área.

• Versión instalada: % de clientes en la última versión comparado con el número de versiones mantenidas
• Índice de uso: % de funcionalidades usadas más del 50% del tiempo
• Ratio de innovación: % del presupuesto dedicado a desarrollar nuevas funcionalidades. A mayor porcentaje, menor Coste de propiedad (TCO).
• Densidad de defectos: % de cambio de bugs en producción desde la última medición
• Product Cost Ratio: Coste total de gastos, incluyendo gastos operacionales/ingresos brutos.

Agregando todas estas métricas podemos tener una idea excelente de cual es nuestra capacidad de innovar. Así, una organización con una gran deuda técnica verá reflejada en esta métrica su deuda técnica, que le impide innovar.

La idea de todas estas métricas, que pueden cambiar de una compañía a otra, es proporcionar un marco para la toma de decisiones, no de ser decisiones en sí mismas. Teniendo una medida continua de estas métricas, que es fácil de obtener mediante los sistemas de información que tienen las organizaciones hoy en día, tendremos un marco que nos permitirá actuar con eficiencia sobre el sistema, independientemente de sus ineficiencias locales.

Leer más

Si quieres leer más, puedes descargar el whitepaper de Evidence Based Management.

Si quieres aprender más sobre como generar y medir valor en tu organización, te recomiendo le eches un vistazo a nuestros próximos cursos de Product Owner en Madrid y Barcelona.