Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

Métricas Ágiles (III)

0 comments
Métricas Ágiles (III)

Midiendo en KANBAN.

En los dos anteriores articulos de esta serie, he escrito sobre los fundamentos de las métricas y sobre las dos principales métricas que siguen los equipos Ágiles. Sin embargo, y sin olvidarnos que el proceso de recogida de indicadores debe ser algo que consuma poco tiempo en el equipo y que realmente sean datos que aporten valor, hay otro conjunto de medidas que pueden ser útiles y que conviene considerar en nuestra estrategia de seguimiento de proyectos, para que tras el análisis de las tendencias que nos den los datos, podamos iniciar mejoras que nos ayuden en nuestros objetivos.

Podemos clasificarlas en

  • Metricas específicas para enfoques Lean/KANBAN.
  • Métricas de Calidad de Código.
  • Métricas  para el Product Owner.

En esta tercer parte de la serie, hablaremos sobre las métricas Lean/Kanban

METRICAS Lean/KANBAN.

Son fundamentalmente tres indicadores.

Lead Time, Cycle Time ( más habituales ) y Process cycle efficiency (%) ( menos conocida pero no por ello menos útil).

Lead Time registra el tiempo que sucede entre el momento en el cual se anota una historia en el Product Backlog ( una vez que se recibe el nuevo pedido o surge una determinada característica o funcionalidad que hay que desarrollar) y el momento de su entrega en producción ( Done ) (el final del proceso del equipo). Se mide en días de trabajo.

Cycle Time : Tiempo de ciclo de una historia. Mide el tiempo transcurrido desde que el equipo inicia el trabajo con una historia,  hasta el final del proceso sobre un PBI ( Product Backlog Item),que culmina con el paso a la columna Done, o Live. ( métrica Lean). Se mide en días de trabajo.

El Cycle Time mide el ritmo de terminación, mientras el Lead Time mide el ritmo de entrega.

La diferencia entre una y otra puede servirnos por ejemplo para medir la “capacidad” del Product Owner en realizar la definición de cada historia con el suficiente detalle como para que sea considerada como “Ready” para que el equipo inicie las tareas técnicas de análisis detallado o diseño técnico o directamente el desarrollo.

 También puede emplearse esta diferencia entre una y otra métrica para aflorar tendencias de “excesiva burocracia” organizativa cuando un PBI debe pasar por largos y pesados procesos de aprobación y validación interna y puede ayudarnos a detectar cuellos de botella organizativos , los cuales, siendo resueltos mejoraran el Lead time y por ende el Time-to-market, contribuyendo a la agilidad de Negocio

Veamos las diferencias entre Cycle Time y Lead Time con un simple gráfico.

Indicadores en Lean Kanban

Estas son las dos métricas más habituales cuando se emplea un enfoque Lean/Kanban, aunque también son perféctamente válidas en equipos Scrum.

Hay otra métrica sobre la que Henrik Kniberg en Lean for the Trenches ( magnífico documento que explica como abordar grandes proyectos con un enfoque Kanban escalando a varios equipos) que me gustaría  comentar en este artículo. % de Eficiencia del ciclo de proceso.

 Se calcula como   % Eficiencia ciclo proceso = Touch Time  / Elapsed Time.

 Donde

 Elapsed time = cuantos días la historia o característica tardó en atravesar el tablero ( igual a Cycle time)

 Touch Time = tiempo en el cual el equipo está realmente trabajando en un PBI (Product Backlog Item) o tiempo que lo “está tocando”. Es decir, cuantos días reales de trabajo costó el  PBI , independientemente de los dias que tardó en llegar a “Done” .  Nos es útil para reflejar los días en los que el equipo no ha podido trabajar en un item, debido por ejemplo a algún impedimento o para detectar situaciones como cambios de prioridades o de tareas muy frecuentes.

 Para reflejarlo en nuestro tablero, nada más sencillo que indicar con algún indicador visual sobre la tarjeta del tablero ( por ejemplo un Punto gordo ), los días que el equipo no ha podido trabajar sobre el item y complementarlo con un apartado en el tablero en el que se indique el “origen de dicho punto”. Es dificil sin embargo obtener información valiosa si no se lleva un tablero virtual.

 Podemos obtener indicadores interesantes. Por ejemplo : en la característica A se emplearon  solo dos días de trabajo,   pero sin embargo tardó 20 dias de Cycle time, asi que la eficiencia fue solo de un 10%.

 Obteniendo estos indicadores podemos enfocarnos a mejorar la eficiencia y a reducir el Cycle time.

 Puede ser una buena manera de “motivar” al Scrum Master o Project Manager a trabajar sobre el impedimento para ayudar al equipo a mejorar el Cycle time de la historia o tarea.

Medir Cycle Time y Lead Time es sencillo.

 La mayoría de las herramientas que podemos emplear para mantener virtualmente nuestros tableros disponen de campos de entrada de datos para indicar las fechas de entrada de la historia, fecha de inicio real y fecha de finalización. Y si no lo tienen, será fácil definirlos en nuestro esquema de datos para los PBI ( tenemos un gran ejemplo de estas posibilidades si usamos Jira + Greenhopper para definir nuestro Backlog con personalización de los campos de entrada de datos, y también tenemos “de serie” gráficos que nos permiten visualizar estas métrica de manera muy visual).

Y si no tenemos tableros virtuales, siempre podemos crearnos nuestras socorridas hojas Excel en las que indicaremos los datos necesarios para poder realizar el seguimiento de los indicadores y analizar las tendencias.

Ejemplo de columnas para analizar indicadores Lean/Kanban.

  1. Número de Issue.
  2. Fecha entrada
  3. Fecha inicio trabajo
  4. Fecha Entrega ( Done)
  5. Touch Time del issue
  6. %Eficiencia
  7. Motivo del Touch time

Y calcular los tiempos Lead time y Cycle Time , simplemente por diferencias.

  • Lead Time = Fecha de Entrega – Fecha de inicio trabajo.
  • Cycle Time = Fecha de Entrega – Fecha de entrada.
  • % Eficiencia = Touch time / Cycle Time.

 Considerando siempre días hábiles, a menos que tengamos la desdicha de tener que trabajar también en “Fines de semana y fiestas de guardar”.

 Cuando tengamos ya una muestra considerable de datos recogidos de nuestros Issues o PBI, entonces es el momento de analizar tendencias.

Algunas ideas que podemos obtener de las tendencias.

Calculamos promedios de cada indicador para su análisis.

Promedio de Cycle Time  es alto :  tenemos un Product Owner que no hace bien su trabajo, una complejidad elevada o  un proceso excesivamente burocrático para la aprobación de un PBI.

Promedio del Lead Time sube :  tenemos sobrecarga de trabajo. Hay algún cuello de botella, el equipo es insuficiente, el ritmo no es adecuado , etc.

Promedio del Lead Time baja : no tenemos suficiente trabajo por que no hay pedidos y el equipo está sobredimensionado, o si somos positivos, el equipo es muy bueno y está trabajando a un ritmo muy bueno.

 Promedio de Touch Time por historia  alto : tenemos muchos impedimentos que requieren una mayor atención por parte del Scrum Master.

 Variabilidad del Lead Time : complejidad muy distinta entre unos issues y otros.

Indudablemente del análisis de estas tendencias, tenemos que sacar acciones de mejora que variarán en función de cada proyecto /equipo.

 Con estas métricas vamos a poder aplicar LEAN con todas las letras , ayudando a eliminar desperdicios allí donde los haya y emprendiendo un camino de mejora continua.

Trackbacks/Pingbacks

  1. Métricas Ágiles – Comunidad Ágiles Paraná | Comentando Libertades - [...] , http://www.gestiondeproyectosit.es/blogit/2012/12/metricas-agiles-ii/ , http://www.gestiondeproyectosit.es/blogit/2012/12/metricas-agiles-iii/ , [...]

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *


*