• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

cumulative flow diagram

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.

 

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.

diagrama de flujo acumulado

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 Limit

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.

customer lead time metric

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 metric

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.

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad