Una de las formas más potentes para experimentar Scrum es hacerlo mediante la comparación. Primero experimentar la construcción de un producto por fases en cascada, para luego vivir la construcción del mismo producto mediante sprints que incorporen feedback y aprendizaje de forma natural.
Alexandre Magno ha ideado la simulación que expongo en este post, me parece excepcional, la hemos liderado juntos y la voy a incluir en mis cursos de Scrum. Para poner contexto explicamos a los asistentes que nuestro hijo quiere invitar a 12 amiguetes a su cumpleaños y necesita 12 tarjetas de invitación. Resulta que le hace mucha ilusión que las invitaciones tengan un payaso sonriente pintado en la portada.
Primera ronda de construcción en cascada
Dividimos a los asistentes en cuatro equipos, y a cada equipo le asignamos una tarea en concreto. Un quinto voluntario hará de tester.
- Equipo 1: dobla y corta una hoja A4 en 2 cuartillas
- Equipo 2: dibuja un payaso
- Equipo 3: colorea al payaso
- Equipo 4: prepara en la parte interior de la cuartilla áreas para el nombre del niño invitado, la fecha y la dirección de la fiesta
- Tester: le damos el payaso original y comprobará la calidad de cada una de las tarjetas construidas
Pedimos a cada equipo una estimación del tiempo que piensa que necesita para desarrollar su tarea específica para crear 12 invitaciones, y los tiempos los apuntamos en una pizarra.
Las fases de construcción las harán de forma secuencial, el equipo 2 por ejemplo habrá de esperar a que el equipo 1 acabe completamente con su trabajo. En la simulación los equipos que no están trabajando estarán ociosos, no es buena cosa. En la realidad esos equipos, o sus miembros, probablemente estén trabajando en otros proyectos, situación que tampoco es deseable, porque cuando el equipo que está en curso haya acabado seguramente el equipo que les siga estará en otra cosa que no habrá acabado todavía. Lo que suele ocurrir en nuestras realidades es que estamos llevando a los equipos al trabajo, y eso no siempre cuadra, ya que planificamos los proyectos en función de la disponibilidad de las personas.
Cuando el equipo 2 haya terminado su trabajo, nos paramos y preguntamos a la sala cuál es el % de progreso. Según los tiempos estimados versus los hechos, suelen decir que están alrededor de un 30% de trabajo hecho, pero no es cierto ya que no probablemente no habrá ni una sola invitación terminada.
Es buen momento para trabajar la diferencia entre proyecto y producto, por tanto que en la gestión de proyectos medimos el progreso por las actividades hechas, y que en Scrum medimos el progreso por los incrementos de producto terminados.
Una vez el equipo 3 haya acabado de colorear los payasos, introducimos un cambio, explicamos a los asistentes que resulta que los niños dicen que sería guay si algunas de las invitaciones tuvieran en su portada a Mickey Mouse.
Los asistentes a la simulación protestarán, dirán que habría que volver empezar desde cero, que no pueden ni aprovechar el trabajo del equipo 1, las hojas dobladas y cortadas en cuartillas, porque el proceso es en cascada y todas las cuartillas ya tienen pintadas al payaso…
Si insistimos en que los niños están demandando a Mikey dirán que es un cambio de alcance, y que es posible si como cliente estamos dispuestos a desembolsar una cantidad similiar al proyecto original. Como ocurre con nuestros clientes en la realidad, un cambio tan pequeño como introducir a Mickey, se convierte el inviable y como cliente nos conformamos con payasos en todas las invitaciones. 🙁
Simulación en la que solo 1 de los 12 payasos pasó calidad
Los equipos siguen trabajando en el proyecto original y acaban por construir las 12 invitaciones.
Finalmente entra en escena el tester que comprueba las invitaciones una a una, comparándolas con la original. Como ocurre en un proyecto en cascada, no podemos obtener feedback hasta el último momento, y como no hemos tenido oportunidad de contrastar, las invitaciones no cumplirán con la calidad y este suele desechar muchas invitaciones… Mostramos y debatimos sobre las diferentes problemáticas que ha detectado el tester.
El equipo 1, cuya tarea es doblar y cortar, suele sentir que ha hecho un buen trabajo, que el fallo no está en ellos, su responsabilidad solo era doblar y cortar y eso está bien hecho.
Los que dibujan y colorean payasos probablemente se sientan mal, porque los fallos o carencias de calidad seguramente estén en sus tareas. En la realidad la situación empeora cuando para solucionar el problema las empresas segregan responsabilidades y definen nuevos especialistas con la idea de garantizar la calidad. Se crearán especialidades como el dibujador de caras de payaso, o el coloreador de pelo… en definitiva una sobrecarga de especialistas y de especialidades que reducirá toda colaboración en y entre los diferentes equipos.
Segunda ronda de construcción con Scrum
Definición de hecho y un cuadro con las
invitaciones que cada equipo estima por sprint
La segunda ronda trata de la construcción de las 12 invitaciones mediante 4 sprints, en los que cada equipo construye tantas invitaciones como considera le puedan caber en un sprint de minuto y medio.
Les damos una hoja A4 a cada equipo y le invitamos a que trabaje como equipo autoorganizado y multifuncional, y que construya invitaciones de principio a fin. En una pizarra anotamos cuantas invitaciones creen que pueden hacer en el primer sprint. Es el momento de introducirles que el el primer sprint es de calibración y que trata principalmente de encontrar su capacidad real, su velocidad.
Suele ocurrir que en el primer sprint no hayan aprendido todavía a colaborar, y a final del mismo no haya ninguna invitación terminada.
Entre sprints hacemos una retrospectiva de medio minuto donde les invitamos a hablar sobre como han trabajado, que ha ido bien, que no y que busquen al menos una mejora para el próximo sprint. Es el momento en el que como trainer podemos incluir dos sugerencias:
- Introducir un límite WIP de 1, instarles a que hagan una invitación tras otra y no inicien varias invitaciones a la vez.
- Y recordarles que el trainer es a la vez el Propietario del Producto, y que en cualquier momento pueden pedirle feedback
Ocurrirán cosas como lo que se puede ver en la foto de la derecha, los equipos encontrarán caminos para la colaboración, llamarán al Propietario del Producto para enseñar las invitaciones y tomar feedback, mejorarán las invitaciones con cada sprint y también mejorarán la forma de como colaboran. Se generará un ambiente alegre y colaborativo con un campo emocional muy energético… lo suelen pasar muy bien.
10 invitaciones exitosas resultantes de los 4 sprints, todas
ellas son un éxito desde la perspectiva del contento de los niños
En el segundo sprint introducimos la petición de los niños de pintar algunas invitaciones con Mickey en la portada. En este punto los asistentes descubren que introducir a Mickey no tiene coste añadido alguno, como mucho puede pasar que haya que descartar alguna invitación de payaso no terminada.
La disponibilidad del Propietario del Producto y la interacción con el mismo hace que florezca la creatividad de los equipos y se produzcan invitaciones cada vez mejores para su propósito: ser atractivas para los niños y animarles a venir a la fiesta de cumpleaños. 🙂
Esta simulación permite introducir los conceptos subyacentes al proceso de Scrum y compararlos con los procesos en cascada que conocen de su día a día. A lo largo de la formación, o acompañamiento posterior, podemos referirnos a situaciones vividas en la simulación, referencias que en la mayoría de los casos son muy esclarecedoras y fáciles de comprender para los asistentes, y ayudan potentemente a fijar el conocimiento recién obtenido.