• 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

método kanban

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.

 

De gestionar personas a gestionar trabajo

Hace unos meses, mi amigo Pedro Ángel Serrano me escribió un correo para preguntarme si había probado Overcooked para Switch. Me decía que le había recordado a lo que vemos en el KSD y el KMP y que refleja muy bien como se originan los cuellos de botellas y se fomenta la colaboración.

Raudo y veloz, hace un par de semanas me lo descargué y me puse a disfrutar de él con mi mujer. Y no podría estar más de acuerdo con Pedro. Overcooked es un juego colaborativo muy sencillo orientado a preparar menús dentro de una historia apocalíptica. Cada nuevo nivel introduce nuecas recetas y retos para poder pasar al siguiente.

Aunque el juego se mueve dentro del dominio de lo complicado y no de lo complejo, es una buena introducción a la organización del trabajo. Después de dos o tres rondas jugando, quedó claro que cada uno de nosotros debíamos de hacernos cargo de una parte de la preparación de los menús y colaborar para darles el toque final (la entrega) o el lavado de los platos.

En Kanban gestionamos trabajo, no personas

He visto a varias personas jugar al juego y veo que intuitivamente tienden a intentar terminar trabajo en lugar de empezarlo (uno de los lemas del método Kanban). Sin embargo, ¿Cual es el problema cuando lo llevamos a un escenario real?

El problema es cultural. Como tradicionalmente el trabajo no sale adelante, tendemos a pensar que es una cuestión de organización o inlcuso de vagancia, así que intentamos controlar el trabajo de las personas, pasando de facto a controlarlas a ellas en lugar de controlar el trabajo.

Uno de los motivos intuitivos es que tendemos a juzgarnos a nosotros por nuestras intenciones y a los demás por sus acciones. Si observamos la portada del libro azul de Kanban, ¿Que nos sugeriría que está pasando si no existiera el tablero detrás de los protagonistas?

En efecto, la falta de información sobre lo que realmente está ocurriendo y que nos aporta el tablero Kanban que hay tras ellos, dejaría toda esta situación en una mera discusión de oficina. La gente no trabaja lo suficiente.

Y así hemos desarrollado unos sistemas muy sofísticados de control de personal. Desde horas trabjadas hasta la gestión de proyecto, los hitos, las propuestas y los comités de revisión. Y sin embargo, ninguna de estas herramientas consigue mejorar nuestra tasa de finalización del trabajo. ¿Por qué? Porque el problema no reside en controlar a las personas.

Para algunas organizaciones, el disponer de métricas directas e indirectas sobre lo que está ocurriendo en las trincheras es solamente un sueño. Así pues, se centran en la productividad, entendiendo productividad como maximizar el número de horas que una persona trabaja.

Cuando algunos alumnos o personas en las organizaciones con las que trabajamos ven Kanban por primera vez, inevitablemente piensan en un nuevo método de microgestión de personas. Y es todo lo contrario.

Sin embargo, ¿Cómo crear el entorno para entender esto?

Protokanban, creando la cultura y evitando la fricción

Protokanban es una herramienta que nos ayuda en este sentido. Sin llegar a limitar el WIP, que sin duda es el paso más difícil en la implementación de cualquier sistema Kanban, nos ayuda a ir cambiando ese prisma de ¿Qué hacen las personas? a ¿Cómo va el trabajo?.

Es un proceso lento que requiere de cierta técnica, en el que al final nos espera el poder empezar a introducir límites WIP y mejorar nuestra capacidad de entregar trabajo, nuestra calidad y la satisfacción de clientes y compañeros.

Además, permite evitar la fricción de introducir un WIP hasta el último momento responsable, que en el caso de Protokanban, es cuando ya contamos con un flujo claro de trabajo y una visualización del mismo.

Si quieres saber más, mi compañero Nacho publicó un artículo introduciendo Protokanban y sus beneficios. También puedes leer nuestra guía del método kanban en el blog.

Proto-Kanban: Qué es y sus beneficios.

Me gustaría compartir mi experiencia ayudando a empresas en la adopción de Lean Kanban y arrojar un poco de luz de este proceso. Este es el primero de una serie de posts donde hablaré de:

  • Proto-Kanban: Qué es y sus beneficios.
  • Downstream y cómo ir más allá de Proto-Kanban.
  • Upstream, discovery Kanban o Kanban de descubrimiento.
  • Cómo encajar al usuario: Upstream, Downstream y Customer Kanban.

Proto-Kanban: Qué es y sus beneficios.

Muchas de las empresas que nos llaman lo hacen con los mismos síntomas:

  • La desmotivación de los equipos es alta. Se sienten totalmente desbordados, con fechas imposibles y cambios de dirección constantes.
  • Los representantes de negocio y los clientes internos/externos se sienten frustrados. Las fechas de entrega no se respetan y la calidad de los entregables es muy baja.
  • El equipo directivo y muchos managers empiezan a pensar que los equipos no están comprometidos o no trabajan lo suficiente.

Tras las primeras conversaciones con el cliente decidimos colaborativamente dónde poner el foco, allí donde podemos aportar más valor. En algunos casos se determina comenzar trabajando en uno o varios equipos implementando Lean Kanban.

Al comenzar el acompañamiento en este nuevo reto, uno de los primeros pasos es facilitar un taller con tres objetivos:

  • Introducir el método Kanban. Necesitamos mostrarle al equipo una idea de dónde se quiere llegar y explicar la diferencia entre el Método Kanban y tener un simple tablón. Si quieres saber más sobre el Método Kanban puedes leer nuestra guía aquí.
  • Experimentar y comprender cómo un sistema pull pude ayudar a satisfacer la demanda y eliminar la sensación de sobrecarga.
  • Explicar el concepto de Proto-Kanban. Llegar a tener un sistema Kanban completo no es algo que se consiga en dos días, y mucho menos en escenarios empresariales de corte tradicional.

Se define Proto-Kanban a un sistema que, sin ser un sistema Kanban completo, ya tiene algunas pautas:

  • Visualización de todo el trabajo y sus etapas en un tablero.
  • Pueden aparecer ya algunas políticas explícitas o algunas clases de servicio.
  • Pueden establecerse también feedback loops: Algunos equipos solo se quedan con la Daily Strandup Meeting. Otros adoptan el Replenishment Meeting, y algunos van más allá y se atreven con retrospectivas.

Proto-Kanban tiene una gran ventaja y es que es poco disruptivo. Uno de los principios de cambio de Kanban es: empieza con lo que tienes; esto es, diseña el sistema para que refleje los procesos actuales, y una vez que lo domines, entonces empieza a mejorarlo colaborativamente. Esto lo convierte en algo más sencillo para comenzar que Scrum, por ejemplo.

Pero si es cierto que, aunque empieces con lo que tienes, existe una gran fricción y resistencia en las empresas a introducir WIP (Work In Progress) limits.  Para superar esta barrera Proto-Kanban ofrece una serie de pasos o estados según la madurez del equipo y de la organización, que te ayudan a ir avanzando:

  • Personal Kanban: Un tablero por persona dónde cada uno visualizará su trabajo.
  • Personal Kanban agregado: Un tablero para el equipo con una fila para cada personal Kanban de cada miembro del equipo. En este momento aún estamos gestionando personas y no trabajo.
  • Team Kanban: Eliminar carriles por persona: Me centro en qué tengo que hacer, pero no en quién lo hace.
  • Introducir WIP Limits por persona: Empezamos a gestionar trabajo y no a las personas.

Proto-Kanban tiene una serie de quick-wins que lo hacen muy potente:

  • Al tener la visualización de todo el trabajo, se toman mejores decisiones.
  • Una mentalidad pull obtiene mejores resultados, priorizan acabar el trabajo antes de empezarlo (start stopping, stop starting).
  • Se generan conversaciones alrededor del trabajo que antes eran imposibles como cómo organizarse para responder a un deadline.
  • Se empiezan a medir y tener gráficas del sistema:
    • Lead time: Tiempo desde que nos comprometemos a tener una tarea hasta que la entregamos.
    • Cycle time: Tiempo que la tarea está desarrollándose.
    • Tasa de entrega: Cantidad de ítems entregados en unidad de tiempo.

En el siguiente post entraremos más a fondo en estas métricas y cómo mejorarlas.

Me gustaría compartir nuestra última experiencia con Proto-Kanban. El escenario es una multinacional con una estructura jerárquica fortísima donde la relación con los jefes es de pánico. Una cultura empresarial basada en micromanagement y donde la comunicación entre equipos y hacia las personas que solicitan el trabajo es inexistente. Además, cada miembro del equipo trabaja de forma aislada a sus compañeros y nadie tiene tiempo de ayudar a nadie.

Cuando el equipo con el que arrancamos la transformación empezó a trabajar con Proto-Kanban, ocurrió un hecho que jamás se había dado en esta empresa. Llegó una petición urgente con fecha de entrega en una semana y…

Primer cambio: Al tener una visualización de todo el trabajo en el tablón, en la Daily Standup Meeting pudieron hablar como equipo basándose en la situación real actual.

Segundo cambio: Se dieron cuenta de que no llegaban si solo una persona cogía la tarea, de manera que la desglosaron en tareas más pequeñas y vieron cómo podrían organizarse para cumplir con la petición.

Tercer cambio: Cuando vieron que aun así no llegaban, decidieron llamar a la persona de su sede central que había realizado la petición. Esto parece algo básico pero nunca había ocurrido en la compañía. Le preguntaron algo de sentido común pero muy poderoso. ¿Qué parte de esta tarea es fundamental para ti, y qué parte puede esperar?

Cuarto cambio: Negociaron con el peticionario y llegaron a un acuerdo de mínimos necesario, que sí se entregó en en una semana.

Conclusión: Por primera vez una tarea urgente cumplió un deadline, el equipo se organizó para alcanzarlo y el representante de negocio estaba feliz.

Al compartir todo esto no pretendo crear una guía que se pueda usar en cualquier equipo o en cualquier situación. Simplemente intento arrojar un poco de luz sobre Proto-Kanban y en qué casos puede funcionar compartiendo nuestra experiencia.

Si quieres saber más sobre mentalidad pull y diferencias entre Proto-Kanban y Método Kanban, puedes asistir a nuestro primer día de la Kanban Week, el TKP (Team Kanban Practitioner)

En el siguiente post hablaré de qué problemas no soluciona Proto-Kanban y cómo seguir avanzando hacía el Método Kanban.

Aquí puedes leer más sobre patrones de madurez de Kanban de la mano del tito Anderson.

Continuar leyendo Flujo Downstream: Cómo ir más allá de Proto-Kanban >>

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