Entendiendo Kanban con el “Ball Flow Game”

Hace ya un buen tiempo facilité el Ball Flow Game de  Karl Scotland. El objetivo del juego es entender la mecánica de Kanban experimentando un flujo continuo,  limitando el trabajo en progreso  y utilizando un enfoque sistémico para mejorar continuamente en cada round.

EspañolEnglish

El juego es una variación del clásico Ball Point Game muy útil para lograr que los participantes sientan el mecanismo de inspección y adaptación en cada iteración en un equipo Scrum. Sin utilizar iteracciones en el “Ball Flow Game”, el objetivo es lograr que el equipo pase a través de todos y cada uno de sus integrantes 20 pelotitas en el menor tiempo possible.

El juego sin duda genera una percepción y punto de vista distinto cuando se le compara con su similar en Scrum ya que las  sugerencias de mejora se apoyan en un análisis cuantitativo en base a estadísticas recogidas en cada round.

Jugamos 5 rounds casi siguiendo las mismas reglas originales, sin embargo, decidí hacer explícitos tres roles : el equipo (10 personas), el cliente, a cargo de introducir pelotitas a una bandeja (Cola de Entrada) y respetando la capacidad acordada con el equipo (limitando la capacidad en progreso) y el Coach (encargargado de la interpretación de los datos estadísticos recopilados en cada round).Vamos a ver a continuación lo que sucedió ya que cada round  fue un experimento enriquecedor.

 

1er ROUND

Dejé que el equipo se  autoorganice  antes de iniciar. Este round fue un poco caótico ya que el equipo pasó por el aprendizaje sobre el proceso mismo de cómo trabajar en equipo! El cliente llenó la bandeja  y un miembro del equipo empujó (hizo”push”) pelotitas dentro del sistema tan rápido como le fuese posible.

Después de pasar la segunda pelotita, el tiempo de ciclo (“Cycle Time”) mejoró y el equipo siguió siendo más o menos constante hasta que en algún momento hubo cierta descoordinación. Tuvieron un ritmo de entrega (“Throughput”) de como máximo 2 pelotitas cada 10 segundos y si nos fijamos en el diagrama de flujo acumulativo es obvio que el sistema estaba siendo suboptimizado con 1-2 pelotitas en proceso en todo momento para un equipo de 10 personas.

Hubieron miembros del equipo improductivos dentro del sistema de trabajo y fue evidente que la persona encargada de recoger las pelotitas de la bandeja de entrada para regresarlas a la bandeja de salida se convirtió en el cuello de botella.  La última pelotita salió del sistema a los 2 minutos 23 segundos.

 

2nd ROUND

Nuevamente  el equipo se  autoorganiza  pero se cambia al miembro del equipo cuello de botella. Esta vez el equipo colaborativamente generó una conversación en la pizarra con el objetivo de re-diseñar el sistema de trabajo para reducir el tiempo entrega (“Lead Time”)  de las 20 pelotitas.

El 2do round  se inició desordenadamente con un tiempo de ciclo  que subió hasta un pico de 43 segundos para la quinta pelotita para luego lograr una mejora del tiempo de ciclo hasta  llegar a un punto de “estabilización”  gracias a un mayor grado de coordinación (10ma pelotita en adelante).

La tasa de entrega mejoró significativamente en comparación con el 1er round. El caos de las primeras pelotitas se puede apreciar en el diagrama de flujo acumulativo,  sin embargo luego de 60 segundos se puede notar una mejora en la productividad del equipo gracias a que se reemplazó el cuello de botella y se logró un flujo continuo.

El reemplazante del cuello de botella esta vez introdujo las pelotitas al sistema más rápido. La cantidad de trabajo en progreso  aumentó a 4 pelotitas, menos holgura y un mejor diseño del sistema de trabajo mejoraron el todo. El tiempo de entrega (“Lead Time”) de de las 20 pelotitas mejoró a 1 minuto 48 segundos.

 

3er ROUND

Se limitó la cantidad de trabajo en progreso a 5 pelotitas a la vez (sin procesarla en lotes). El cliente colocó  5 pelotitas en la bandeja de entrada con el objetivo de que un miembro del equipo alimente al sistema a un ritmo de “pelotita que entra pelotita que sale”.

A pesar de tener un proceso impredecible debido principalmente a un mal re-diseño del sistema que dificultó la coordinación y causó una importante cantidad de bugs (pelotitas caidas), limitar el trabajo en proceso mejoró el tiempo de ciclo de cada pelotita (con el mayor pico en 27 segundos aprox.) en comparación con el 2do round (con el pico más alto a 44 segundos).

A pesar de las dificultades, el todo mejoró y el tiempo de entrega de las 20 pelotitas bajó a 1 minuto 36 segundos!

 

4to ROUND

Reflexionamos en base al sistema de trabajo anterior y descubrimos los beneficios de experimentar acordando limitar la cantidad de trabajo en progreso explícitamente. Esta vez el equipo aumentó el límite a 6 pelotitas ya que el equipo sentia que no estaba siendo del todo productivo.

El ritmo de entrega fue alto desde un inicio y el análisis cuantitativo mostró un alto grado de predictibilidad, en general hubo una reducción en el tiempo de entrega de las 20 pelotitas a 1 minuto 18 segundos, mucho mejor en comparación con los anteriores rounds!

 

5to ROUND

El equipo decidió probar cambiar nuevamente a la persona encargada de introducir y sacar pelotitas del flujo. Se aumentó la cantidad de pelotitas en progreso a un límite de 7 para encontrar un balance natural entre capacidad y demanda.

Esta vez se alcanzó un grado superior de coordinación, no hubieron bugs (pelotitas caidas), las estadísticas mostraron una fluctuación mínima alrededor de la media (tiempo de espera promedio) que fue de sólo 8 segundos y el rendimiento después de 20 segundos se mantuvo constante a un ritmo de 4 pelotitas cada 10 segundos hasta evacuar  las últimas 3 pelotitas fuera del sistema.

El diagrama de flujo acumulativo es más pronunciado  en comparación con el round anterior anterior y refleja el hecho de que ahora tenemos un flujo constante y suave. El proceso es ahora altamente predecible y está totalmente bajo control.  El tiempo de entrega de las 20 pelotitas batió recods y fue de 57 segundos!

Conclusiones

Hemos pasado por un proceso de mejora continua en base a data cuantitativa. Se midió cada instancia del proceso para en base a data recopilada generar distintas perspectivas y diseñar experimentos de nuestro sistema de trabajo. En el 5to round hemos logrado la máxima aspiración de cualquier cliente,  que es finalmente un sistema de trabajo  donde se puede entregar una cantidad de items (en este caso 4 pelotitas) a un ritmo sostenible y predecible.

Con un simple experimento hemos visto que es lo que sucede cuando utilizamos Kanban. Logramos balancear la capacidad contra la demanda de trabajo que se nos impone en el día a dia. Nos detenemos por un momento para pensar en cómo mejorar el sistema de trabajo en el que estamos inmersos y descubrir colectivamente nuestros limites.

En un contexto donde el trabajo se hace visible, continuamente se reflexiona con el soporte de data cuantitativa. Se remueve el desperdicio y se mejora colectivamente para finalmente alcanzar reducción en los tiempos de entrega, alta calidad, productividad y predictibilidad en los procesos.

Cierro finalmente el post con una conocida frase de Edwards Deming:

 En Dios confio, pero el resto que me traiga data! Edwards Deming

 

The aim of the “Ball Flow Game” is to experiment flow, WIP limits and a systemic approach to continuous improvement. This game is a variation of the classic Ball Point Game used to teach Scrum and make the participants feel the inspect and adapt mechanism.

With no iterations, the aim of the game is to pass 20 balls through the whole team in the shortest possible time. It was interesting enough how the “Ball Flow Game” generated a different perspective and team dynamics compared to the “Ball Point Game”. Suggestions for improvements were supported by quantitative analysis based upon statistical data collected in a per round basis.

We ran the 5 rounds pretty much following the same original rules, however I decided to make 3 roles explicit: the team, the customer (in charge of feeding balls to an INPUT bin and respecting the capacity agreed by the team) and me as the Coach (in charge of the collection and interpretation of the statistics available in each round), so let’s see below what happened since each round was an experiment!

 

ROUND 1

We let the team self-organize before starting. This round was a bit sloppy since we started to learn how to work as a team, basically the customer filled out the INPUT bin and one team member started to “push” balls into the system as fast as he could. After the second ball we could say that cycle time improved and remain pretty much constant up until losing up a bit of coordination at some stage.

Throughput had a maximum of 2 balls per every 10 seconds and if you look at the Cumulative Flow Diagram it was pretty obvious that the system was underutilized with a WIP of 1-2 balls at a time for a 10 people size team. Therefore there was a lot of slack in the system and it was very clear that the person collecting the balls from the INPUT bin and returning them back to the OUPUT bin was the bottleneck.

The last ball came out at 2 minutes 23 seconds.

 

ROUND 2

I again let the team self-organize and decide changing the team member who was the bottleneck. This time the team collaboratively brought the discussion to a whiteboard with the aim of looking at the best system design to reduce the lead time for the 20 balls.

Round 2 started a bit chaotic with an increase in cycle time (43 seconds) for the 5th ball followed by an aggressive reduction up until reaching a point of “stabilization” (10th ball onwards) thanks to a better degree of coordination. As a result we had a clear improvement in throughput compared to round 1.

Chaos is reflected in the Cumulative Flow Diagram as per the first few balls; however after 60 seconds have elapsed it shows better utilization of people due to removal of the bottleneck and improvement of flow. The replaced team member introduced balls faster, the average WIP increased to almost 4 balls at a time, less slack and a better system design improved the whole. The overall lead time for the 20 balls improved to 1 minute 48 seconds. 

 

ROUND 3

In this round we suggested to put a WIP limit of 5 balls at a time (without batching them). The customer dropped 5 balls to the INPUT bin so a team member could feed the system at the rate of one-in one-out.

Despite having an unpredictable process mainly due to a bad system design which hindered coordination and caused a significant amount of “bugs” (balls falling off) limiting the work in progress improved cycle time per ball (with the highest spike at 26 seconds) compared to round 2 (with the highest at 44 seconds). The whole was improved and overall lead time for the 20 balls went down to 1 minute 36 seconds!

 

ROUND 4  

We reflected upon the previous round work system design and discovered the benefits of experimenting with explicit WIP limits. This time we increased the WIP limit to 6 balls since we believed we still had a bit of slack we could take advantage of. Throughput was high right from an early start and the analysis showed a high level of certainty.

The Cumulative Flow Diagram also reflected this predictability and overall we had a reduction in Lead time to 1 minute 18 seconds, much better compared to the previous rounds!

 

ROUND 5

This round was the best of all, the team self organized and decided to try out again changing the person in charge of the INPUT/OUTPUT bins. We increased the limit to 7 balls to see how far we could stretch out the system. This time we achieved the highest degree of coordination, no bugs (balls falling down), statistics showed minimum fluctuation around the mean, the average lead time was just 8 seconds and the throughput after 20 seconds was kept constant at 4 balls every 10 seconds up until flushing the last 3 balls out from the system.

The Cumulative Flow Diagram is steeper compared to the previous round reflecting the fact that now we have a very smooth flow. The process is now highly predictable and completely under control, this is what customers like, right? Imagine the level of trust you would generate if based on facts you tell your customer that every week you are consistently delivering 4 features at a sustainable pace. Overall time went down to 57 seconds!

 

Conclusions  

In each round we improved based in a concrete quantitative data analysis, we studied and understood the capability of our system to deliver and we experimented with changes in order to make it more predictable whilst we progressed. We achieved higher quality and productivity, this is what we aim for when we develop software in today’s world of uncertainty, don’t you agree?

Comparte...Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+
Manuel Mazán

Manuel Mazán

Fundador de Agiland en el 2010 y Consultor internacional en Metodologías Ágiles e innovación. 20 años de experiencia internacional trabajando en Perú, España, Irlanda y UK. Pionero aplicando el método Lean Kanban en Perú. Manuel ha llevado a cabo transformaciones ágiles exitosas a nivel de equipo y a escala. En el 2015 lideró la transformación ágil de la banca digital en BBVA Continental. Ingeniero de Sistemas (Cum Laude) Universidad de Lima. MBA Ulster University (UK). Certified Scrum Master (CSM), Certified Scrum Professional (CSP), Scaled Agile Framework (SAFe) Program Consultant, Facilitador Management 3.0 y PNL Practitioner. Expositor internacional Lean Kanban Southern Europe 2012 España, Ágiles 2012 Argentina, Ágiles 2013 Perú,Ágiles 2014 Colombia y ScrumDay Perú.
Manuel Mazán
Tagged with:
Posted in Blog

Enviamos a tu inbox noticias y te mantenemos al tanto con lo mejor de nuestro
BLOG

¡Al suscribirte te daremos acceso inmediato a un caso de estudio tipo "White Paper" y un cupón GRATIS a un curso online!

Leénos en FB !

Algunos testimonios de nuestros cursos

Este curso me ayudo a entender los diversos conceptos relacionados con el mundo LEAN y me ayudó a darme cuenta que en el proceso actual de desarrollo de software de mi empresa se estaban cometiendo muchas ineficiencias que no generaban valor al producto final. Definitivamente este curso es 100% recomendable.        
Marco CarranzaGestión de Proyectos exitosa con Lean Software Development
Curso muy Dinámico. El instructor sabe llegar a los alumnos. Casos prácticos que ayudan a entender los conceptos
Kristel NuñezTaller de Incepción al Framework Ágil Scrum
El contenido del curso y la exposición de los temas es muy bueno, cumple con las expectativas del mismo y aporta valiosa información al respecto del tema principal del mismo. Adecuado para aplicar en casos del día a día. Recomendado!        
Hernando RondónPrincipios para entender y aplicar Agile, Scrum, XP y Kanban
Uno de los mejores cursos de metodologías ágiles que he llevado a lo largo de mi carrera profesional, la metodología didáctica y el conocimiento profundo de la materia hace de este curso sea uno de los mas recomendables en su linea.
César Garrido LeccaTaller de Incepción al Framework Ágil Scrum
Este es un curso sencillo, claro de entender y muy preciso. Mis expectativas fueron cubiertas en un 100%. Lo recomiendo ampliamente para aquellos que (como yo) se encuentran en proceso de implementar este tipo de metodologías para mejorar su trabajo día con día.        
Jesús V.Principios para entender y aplicar Agile, Scrum, XP y Kanban
Curso que explica de manera clara las bases fundamentales para llevar acabo un proyecto de software de manera exitosa, ideal para aquellos que nos encontramos inmersos dentro de la gerencia de proyectos. Este curso toca temas y problemas reales con los que uno tropieza al liderar proyectos de este tipo. Buen curso.        
Christian DelgadoPrincipios para entender y aplicar Agile, Scrum, XP y Kanban
El curso me pareció muy interesante y sobre todo dinámico que es lo que me ayudó a entender mucho mejor los fundamentos del Scrum
Francisco CalderónTaller de Incepción al Framework Ágil Scrum
Manuel, tiene la facilidad de simplificar los conceptos y pone en práctica lo enseñado de una manera ágil y amena. El entrenamiento logrado ha sido excelente para poder aplicar las metodologías ágiles en los proyectos de desarrollo de software
Carlos PeraltaGestión de Proyectos Lean-Agile
Un curso obligado para comenzar a entender estos conceptos. Muy bien explicado. Me resulta difícil dar una reseña completa del curso porque se presentan varios conceptos nuevos para mi y además se emparejan con conceptos de manufactura, en definitiva debo leer el libro que recomienda al final del curso. La valoración tan alta la doy porque el instructor tiene una excelente fluidez al explicar los puntos tratados y un dominio en los temas que mantiene toda mi atención y crea mayor interés p…
Felipe De Jesús Piña Gestión de Proyectos exitosa con Lean Software Development
Aprendizaje con casos y dinámicas, perfecto! Usa la experiencia para asimilar conceptos
Jose Luis SánchezTaller de Incepción al Framework Ágil Scrum