martes, 14 de mayo de 2013

Actividad: Ball Point Game. Ilustrando un proceso iterativo y su mejora continua


Esta actividad es una adaptación del juego creado por Boris Gloger  y de la explicación ofrecida por Declan Whelan. Este interesante y entretenido juego ilustra la dinámica de un equipo trabajando de forma iterativa y en mejora continua mediante retrospectivas. Para ilustrar  Scrum y su proceso iterativo prefiero otras actividades (ver Scrum + Kanban + conceptos Equipo Self-organizing y Cross-functional). Mi interés por esta actividad es más por lo que respecta al hábito y conveniencia de realizar mejora continua mediante reuniones de retrospectiva.

Esta actividad tiene una duración aproximada de 30 minutos.

INDICACIONES

El objetivo en el juego es pasar tantas bolas como sea posible a través de cada miembro del equipo en 2 minutos. Se contabilizará cada bola pasa a través de todos los miembros del equipo siempre que la primera persona que toque la bola sea también la última en tocarla. Se realizarán 5 iteraciones. Antes de cada iteración el equipo estimará cuántas bolas piensa que va a conseguir pasar hasta el final. Después de cada iteración se registrará el número de bolas conseguidas.

Material
Boris Gloger recomienda bolas de tenis pero podría hacerse con cualquier objeto que pueda ser lanzado con facilidad. Dependiendo de la cantidad de participantes, prever una cantidad adecuada para que no tengan que esperan demasiado a que les lleguen bolas (considerar que las bolas que llegan al final se contabilizan y se vuelven a poner en el circuito).

Reglas del Juego
- Casa bola debe pasar por todos los integrantes
- La bola debe pasar por el aire
- No pasar la bola al vecino a izquierda o derecha
- Integrante de inicio = Integrante de término
- Iteración = 2 min
- Tiempo entre iteraciones = 1 min
- Haremos 5 iteraciones
- Si la bola cae al suelo o no cumple alguna regla se computará un fallo


Guía de la actividad
- 2 min. para introducción
- 2 min. para comentar de normas
- 2 min. para preparar primer sprint
- Realizar 5 iteraciones:
          - Registrar la estimación del equipo
          - Registrar la mejora que se aplicará en el sprint (a partir del segundo sprint)
          - 2 min. de iteración
          - Registrar bolas conseguidas y fallos
          - Aproximadamente 2 min. de retrospectiva
- 10 minutos comentarios finales
Crear una hoja o transparencia para que las reglas del juego estén siempre visibles. 

Revisando la información en internet, vemos que Ball Point Game es usualmente realizada al principio de un curso o seminario de Scrum, principalmente con el propósito de "romper el hielo" entre los asistentes. Para ello solo se forma un equipo con todos los asistentes, esperando intencionalmente que se cree un cierto caos, lo cual también resulta divertido. En nuestro caso el propósito es diferente, nos centramos en destacar el valor de las retrospectivas (después de explicar métodos y prácticas ágiles, en un apartado de Mejora Continua). Así, para asegurarnos que exista posibilidad de realizar buenas retrospectivas, en las cuales todos tengan la posibilidad de participar, nuestra recomendación es que los equipos no tengan mucho más de 10 personas, así pues, realizamos el proceso en paralelo con varios equipos a la vez, yendo todos a la par en cuanto a tiempos, sprints e indicaciones. 

Preparar (para cada equipo) una tabla como la siguiente donde registrar los resultados de cada iteración.


Sprint
Bolas
Estimadas
Bolas Reales
Fallos
Mejoras
1




2




3




4




5





Asegúrese de disponer de un espacio suficiente para que el equipo pueda experimentar diferentes posiciones de sus integrantes.

Indicaciones adicionales
  • Que el instructor registre los resultados y complete la(s) tabla(s) de datos, así los equipos se concentran en los sprints y en las retrospectivas.
  • Recomendable usar StopWatch como cronómetro para la cuenta regresiva de 2 min. en cada sprint.
  • Cuando pregunten ¿se puede hacer tal cosa?, simplemente remitirlos la las reglas del juego diciendo  "es vuestro proceso”.
  • Recuerde registrar las mejoras que realicen en el proceso inmediatamente después de la retrospectiva.
  • Recuerde solicitar una estimación de bolas antes de comenzar cada sprint.
  • Al terminar el sprint antes de comenzar la retrospectiva dejar todas las bolas preparadas para el siguiente sprint, así el equipo estará centrado en la retrospectiva pensando en mejoras. 

COMENTARIOS FINALES

Algunos temas de debate:
  • ¿Qué iteración funcionó mejor?,  pero ¿qué entendemos por “mejor”?
  • ¿Se consiguió una mejora continua, fueron eficaces las retrospectivas?. Es importante valorar las reuniones de retrospectiva puesto que la mejora en productividad y calidad del trabajo, y compromiso y moral del equipo puede ser muy rentable respecto del tiempo invertido en dichas reuniones.
  • Establecer paralelismos entre Scrum y el Ciclo de Deming (Plan-Do-Check-Act).
  • Pull Systems. La mayoría de los equipos establecen de forma natural un Pull System, es decir, no se produce o avanza la producción si no hay demanda desde la parte que recibe bolas. En nuestro caso existe un límite para el WIP, correspondiente a cuántas bolas puede tener una persona en sus manos. 
  • ¿Qué tipo de liderazgo se generó, se tomaron en cuenta todas las ideas?. La energía o ímpetu por proponer mejorar puede llegar a generar conflictos. En el ámbito laboral intervienes otros factores asociados a las iniciativas de mejora, tales como: el reconocimiento, la recompensa, la autoridad, etc.
  • ¿Es siempre posible mejorar el proceso? ¿Existe un ritmo o velocidad natural en cada proceso?. Manteniendo una misma configuración en iteraciones sucesivas, por simple práctica,  se conseguirá mejorar los resultados y reducir los fallos. Sin embargo, sin hacer cambios, cada vez la mejora será menos significativa. Esto es normal, pues un sistema tiene un cierto rendimiento una vez alcanzado su estado de eficiencia, en el cual a menos que se introduzcan nuevos cambios, permanecerá estable y predecible. Es decir, esta situación de estabilidad en eficiencia no es mala, pero no debería llevarnos al conformismo o descartar la búsqueda de nuevas mejoras. Tampoco debemos estresar el sistema presionando por más velocidad de la que puede dar de forma natural.
  • Puede presentarse el caso en el cual con una nueva configuración se obtenga un resultado peor, incluso llegando a abortar la iteración si está siendo desastrosa. Esto no debería verse como un fracaso, es un aprendizaje :-) , y siempre podría volverse a una situación previa de la cual se conocía su desempeño.
  • Respecto de un trabajo de equipo real, la gran simplificación en este juego es que generalmente los ítems de trabajo (las bolas de este juego) no requieren el mismo esfuerzo para procesarlas. En desarrollo de software si dos o más ítems son exactamente iguales, solo se desarrollaría una vez y luego simplemente se reutilizaría. Sin embargo, en muchos casos el equipo se enfrenta a ítems de diverso tamaño y/o complejidad, es decir, el juego equivalente tendría bolas de distinto tamaño, peso, etc., con lo cual quizás el proceso debería adaptarse a las características de cada tipo de ítem.

INSTANTES DE LA ACTIVIDAD




No hay comentarios:

Publicar un comentario