métricas

Kanban Metric Layout (II)

En el primer post de la serie Kanban Metric Layout hablamos sobre los indicadores más importantes. En este post vamos a ver las gráficas dónde podremos ver e interpretar esos indicadores.

Gráficas

Cumulative Flow Diagram (CFD)

El CFD es una gráfica muy completa que nos permite leer multitud de indicadores y analizar tendencias.

Lead time: Si trazas una línea horizontal desde la línea que representa el punto de compromiso hasta la línea que representa que el elemento está entregado tendremos el Lead Time Medio medio aproximado (que no tiene por qué parecerse al lead time de PBIs individuales, por ejemplo, cuando haya cosas muy viejas en el backlog).

Cycle Times: Podrás obtener el cycle time medio aproximado si trazas una línea horizontal desde dónde empezamos el trabajo (In progress en el ejemplo) hasta que hemos terminado (ready to approval en el ejemplo).

Throughput: La pendiente de la línea de completados es el throughput medio en ese intervalo de tiempo.

WIP: Trazando una línea vertical desde el estado completado hasta el primer estado de trabajo de nuestro flujo obtendremos el WIP en ese momento.

Para equipos que aún no han limitado el WIP esta parte puede ser muy útil para establecer una conversación sobre el tema (extra: ¿Cómo elegir un buen WIP limit?). La relación entre WIP, Lead TIme y Throughput está queda bastante clara en el CFD:

Para que el Lead Time no se dispare debemos terminar el mísmo número de elementos que empiezo. De manera que las líneas en el CFD del trabajo comenzado y terminado deberían ser paralelas:

Si tenemos dos líneas divergentes significa que estamos empezando más trabajo del que estamos acabando, por lo que nuestro lead time aumentará y nuestra predictibilidad bajará. Esto es justo lo que intenta evitar Kanban limitando el trabajo en curso.

Cycle time Scattlerplot

Es la principal gráfica para visualizar y analizar los Cycle Times. Los equipos pueden fácilmente comprender las tendencias.

Una de las herramientas más poderosas de este gráfico son los percentiles. Son las líneas horizontales discontinuas que terminan en un porcentaje. La más alta de todas, la del 95%, significa que el 95% de los puntos de la gráfica están por debajo de esa línea. Estos percentiles nos permiten saber, por ejemplo, que el 50% de las veces el cycle time está por debajo de 7. También, con los datos que observamos en la imagen, si alguien nos pide un desarrollo en 16 días, estaremos en situación de decirles que se lo entregamos con un 85% de posibilidades en el plazo solicitado.

Además, se podían usar colores para distinguir entre tipos de trabajo, clases de servicio, etc… y tener datos de cada uno de ellos.

Histogram Cycle Time

Los histogramas son gráficas claras y sencillas de leer. Por eso, el histograma de Cycle Time es muy utilizado.

Los datos que podemos ver son los parecidos a los del Cycle time Scattlerplot pero agregados por frecuencia. Esta vez, en vez de ver toda la nube de puntos observaremos la frecuencia de cada uno de los valores de cycle time

Tal y como nos pasaba con el Scatterplot, el histograma nos permite entender como funciona nuestro Cycle Time, detectar valores anómalos y observar percentiles. La gran diferencia es que este gráfico, al no tener un eje temporal, no nos permite analizar tendencias. Pero, para muchos, es el que muestra los datos de forma más clara y permite analizar los datos de forma más sencilla.

Throughput Run Chart

Para analizar tendencias en nuestro Throughput podemos usar un Run Chart dónde podremos ver los elementos terminados por unidahttps://www.pqsystems.com/qualityadvisor/DataAnalysisTools/run_chart.phpd de tiempo. Esto, junto con el trazado de una línea de la media, nos permite ver claramente tendencias en nuestro Throughput.

En el siguiente ejemplo podemos ver los elementos terminados en 100 días agregados por semana.

Aging Work in Progress

La edad de los ítems dentro del sistema es uno de los datos más usados a la hora de tomar decisiones pull. Es importante tener en cuenta cuando entraron en el sistema para intentar garantizar los SLA o SLE.

Si además le añadimos zonas de riesgo por colores podremos ver de una forma muy visual aquellos ítems que están en riesgo.

En el siguiente ejemplo vemos el Work Item Age (los puntos) para los elementos dentro del sistema. Además, vemos 5 estados diferentes en nuestro workflow y, para cada uno, tenemos las zonas de menor riesgo (verde) hasta la zona de mayor riesgo (roja). Con esta información podemos saber que en el último estado hay dos elementos en zona de riesgo medio, y dos en zona de riesgo más alto. Cuando hablamos del último estado suele ser fácil saber este tipo de situaciones. Pero la potencia de esta gráfica radica en que ahora sabemos que el ítem en la primera columna está entrando en zona de riesgo alto. Y que en la segunda ya tenemos dos que han entrado y debemos tener una conversación sobre qué hacemos.

Además, esta gráfica suele venir con nuestros amados amigos: los percentiles.

Conclusiones

Me gusta pensar en Lean Kanban como una manera de profesionalizar los servicios que un equipo ofrece a sus peticionarios. Esto nos exige continua mejora y la búsqueda constante de nuestra predictibilidad. Solo midiendo las métricas correctas podremos asegurar un flujo continuo, estable, altamente previsible y potencialmente mejorable.

Espero que os sean de utilidad estos posts. ¿Echas de menos alguna métrica o indicador? No dudes en compartirlo con nosotros en los comentarios.

#ScrumClinic: De Proyectos cerrados a Proyectos Agiles

Hola Jerónimo,
He descubierto tu página hace poco y desde entonces soy un asiduo a ella. Es más a raíz de tus posts ya tengo en mis manos el libro de Scrum – A pocket guide de Gunther Verheyen.

Te cuento, he estado 5 años trabajando en una empresa de IT que apuesta muy fuerte por las metodologías ágiles. Hace 7 meses cambié a otro sitio y aquí me está costando mucho hacerles ver las ventajas de trabajar con Scrum frente al waterfall tradicional.

Aquí cuando entra un proyecto nuevo, en base a una estimación sobre suposiciones se elabora un plan de proyecto y una oferta económica que acaba siempre en incumplimientos de fechas de entrega y budgets.

Como ahora me toca más de cerca el tema de los presupuestos no tengo muy claro cómo hacer con Scrum para presupuestar un proyecto. Te pongo ejemplos. Si en una fase inicial donde apenas conocemos el alcance del proyecto y el cliente está pidiendo un presupuesto, o incluso si nos presentamos a un concurso, cómo podemos hacer para decirle al cliente lo que le va a costar el proyecto?

Scrum se basa en el empirismo y en la confianza entre cliente y proveedor, pero cómo le puedes decir a un cliente que de primeras no tienes ni idea de lo que le va a costar el proyecto y que hasta digamos la mitad del transcurso del proyecto no tendremos una idea aproximada de lo que puede llegar a durar (y por tanto) costar su proyecto.

Muchas gracias por adelantado!

Alberto Gómez

El mito del 100% de certidumbre

Me parece una pregunta muy interesante, y quizás la respuesta que pueda dar parezca sorprendente. Vamos allá:

Cuando te pregunten por proyectos cerrados, responde con complejidad y métricas de predictibilidad. NO discutas sobre lo indiscutible. En lugar de eso fomenta una conversación que ayude a pensar en cómo mejorar.

Una de las habilidades más importantes como Scrum Master es tener la capacidad de establecer el contexto adecuado a la hora de hablar de problemas y soluciones. Ver más allá de la cuestión e intentar establecer nuevas ideas para que las personas con las que trabajamos puedan desarrollar su propia visión de las cosas.

El caso que me comentas me lo he encontrado muchas veces a lo largo de mi carrera. A pesar de querer utilizar Scrum, las organizaciones insisten en tener fechas, alcances y precios cerrados. Lo ven como un factor de reducción de la incertidumbre y algo a lo que agarrarse en caso de que las cosas vayan mal. Y es que las cosas irán mal. Y no porque no hagamos nuestro mayor esfuerzo en ceñirnos al plan. Sino porque el plan, desde el primer momento que lo escribimos, está mal.

El desarrollo de Software como entorno complejo

Déjame presentarte a Dave Snowden. Es uno de los contribuyentes más importantes al movimiento ágil y sin embargo, despotrica de Scrum cada vez que tiene oportunidad ¿Por qué? Porque ve como Scrum se ha convertido en el palo con el que las organizaciones atizan la complejidad.

Dave es experto en complejidad. Basándose en el trabajo de Ralph Stacey, ha creado el framework Cynefin (Pronunciado Kin-fin) dentro de su compañía para explicar este concepto.

Sí, los planes funcionan en entornos simples y en parte de los complicados, pero en el momento que aumentamos la complejidad, es imposible mantener un plan y de tontos intentar ceñirte a él. En esos entornos, es mejor contar con una forma de trabajo que permita inspeccionar y adaptar.

Te daré un ejemplo. Si tengo una habitación que mantener a la misma temperatura todo el día, ¿Cuantas variables influyen?

Muchas. Muchísimas.

¿Tendría sentido hacer un plan para todo lo que hay que hacer en la habitación (poner el aire, quitar el aire, poner la calefacción, abrir las ventanas) para ejecutarlo una vez al día? ¿O tendría más sentido utilizar un climatizador, que se encarga de inspeccionar la temperatura y adaptarla? Scrum es al Software lo que el climatizador es a la habitación. Nos permite descartar variables, inspeccionar y adaptar en entornos complejos.

Para aquellos clientes que demandan predictibilidad, no hay más que utilizar herramientas que tienen en cuenta la complejidad, como son el cono de incertidumbre, No Estimates o el uso de simulaciones de Montecarlo para poder estimar basados en situaciones previas.

Ten en cuenta que el truco es tener un histórico. Si no existe un histórico de delivery de ese equipo en ese proyecto, es imposible dar ningún tipo de predictibilidad. Tampoco si el equipo ha estado en otro proyecto. Lamentablemente este es el mundo del Software. No importa cuanto le grites a un cable, no va a transmitir más bits por segundo.

La próxima vez que te veas en esta situación, en lugar de decir ¡No se puede!, intentar crear una conversación sobre complejidad y sobre la experiencia de la compañía en el pasado con estas situaciones, para dar paso a una discusión sobre métricas alternativas de predictibilidad que ayuden al cliente y a la organización a entender mejor el proceso.

Por último te recomiendo un libro: Actionable Metrics for predictability, que ahonda mucho más en este tema.

Con paciencia y perseverancia, empezarás a tener conversaciones que hagan que el rumbo de la compañía cambie.

Métricas ágiles fundamentales (II)

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.

Métricas ágiles fundamentales (I)

La principal medida de progreso en marcos de trabajo ágiles no son los puntos de historia, sino el software terminado. Muchos equipos siguen utilizando una medida de estimación subjetiva como una métrica absoluta para predecir. Malas noticias. Los puntos de historia (story points) no sirven para nada. Las buenas. Existen varias métricas ágiles que son fundamentales y pueden empezar a usarse inmediatamente. Veámoslas.

Métricas Macro

Las métricas macro son aquellas que permiten obtener información a alto nivel de una pila de tareas por hacer, lo cual permite tomar decisiones o plantear teorías para el conjunto de equipos que desarrollan un producto.

El Cumulative Flow Diagram (CFD)

Este diagrama indica cuantos Product Backlog Items hay en cada uno de los estados del backlog. Para obtenerlo, se puede usar software -en el caso de la imagen, JIRA- o de forma manual de forma muy sencilla. Esto es, dibujando un diagrama, y al final de cada día, actualizando el valor acumulado de cada uno de los elementos que tenemos en el Product Backlog.

WIP

La primera de nuestras métricas ágiles es el WIP. El WIP nos indica en cualquier momento el trabajo que está en curso. Si miramos el diagrama detenidamente, podemos obtener el trabajo en curso en cualquier momento midiendo la distancia entre el trabajo pendiente del backlog y el trabajo que todavía no ha sido entregado. Esta medida nos indica, de un vistazo, si los equipos están trabajando en demasiadas cosas a la vez.

Reducir el trabajo en curso contribuye a reducir la frecuencia de entrega. En entornos ágiles, las entregas frecuentes son muy importantes y permiten obtener un feedback rápido del cliente para poder adaptar la estrategia.

Algunas organizaciones tienen 6 o más meses de trabajo en curso. ¿Que significa eso en métricas de negocio? Que existe una inversión que no está produciendo ningún resultado y que conforme pasa el tiempo, reduce su posible retorno (ROI) y por tanto aumenta el riesgo. Reducir el trabajo en curso se hace más fácil relacionando las métricas de producto con las métricas de negocio de esta manera.

De esta manera, se justifica la necesidad de introducir técnicas de Continuous Delivery o DevOps en los equipos de desarrollo, o incluso de refactorizar la base de código para facilitar entregas más frecuentes.

Average Customer Lead Time

Si trazamos una línea horizontal en el diagrama de flujo acumulado, obtenemos el tiempo medio de entrega al cliente para el conjunto de nuestro Product Backlog. A pesar de ser un concepto de Scrum, también se puede utilizar en Kanban u otros métodos.

El tiempo medio de entrega al cliente nos dice cuanto pasa, de media, desde que ponemos algo en el backlog hasta que esto está entregado. Es un concepto macro. Puede que haya elementos del backlog que normalmente tarden mucho menos o mucho más.

Si un equipo no se siente identificado con un customer lead time muy alto ya que normalmente tardan poco en completar los ítems, hay que observar varios factores.

El primero es si la definition of done de ese equipo permite realmente poner el software en producción. Que una tarea esté hecha por el equipo y tenga que esperar un proceso de puesta en producción hace que su ROI descienda con el tiempo.

El segundo puede ser que el Product Backlog se haya convertido en la “carta a los reyes magos”. Eso hace que las posibles ideas junto con el análisis de su beneficio vayan perdiendo sentido con el tiempo y que el Product Owner no esté trabajando lo suficiente para mantener un backlog que aporte valor al negocio.

Cycle time

Si trazamos la diagonal entre el WIP y el Customer Lead Team, obtenemos el tiempo de ciclo. Esto es, el tiempo que el equipo pasa trabajando en la tarea hasta que esta está entregada. Esto no es el tiempo real que un desarrollador tarda en realizar la tarea, sino el total desde que se empezó hasta que se dio por terminada.

Se puede ver la relación obvia entre estas tres métricas. Reducir el WIP afecta al customer lead time y al cycle time. Para reducir el Cycle Time no nos queda más remedio que reducir el Customer Lead Time.

La ley de little

En realidad, todo esto tiene un nombre: la ley de Little. Este señor demostró la relación entre el número medio de clientes en una tienda, su frecuencia de llegada y el tiempo medio que pasaban en la tienda. A pesar de sonar bastante inofensivo, es la base de Kanban.

Por otro lado, aunque usemos Scrum, podemos tratarlo como un sistema Kanban, dado que tenemos acceso a el diagrama de flujo acumulado del cual podemos extraer las métricas. En otro artículo hablaré de cómo hacerlo con números.

Así, si una organización quiere aumentar la agilidad ofreciendo software en ciclos más cortos, no tiene más remedio que invertir en mejorar las herramientas que favorecen que el software se ponga en producción, esto es, operaciones y desarrollo. Aquí entra en juego el factor humano. No se puede simplemente añadir más miembros a un equipos, sino que requiere tener en cuenta otro triángulo de hierro: El de infraestructura/arquitectura, producto y personas. En el próximo de la serie, hablaremos de métricas micro.