“El expendedor” es un juego de 75 minutos para equipos a los que se explica por primera vez Scrum. Permite que hagan una simulación de creación de la lista de objetivos priorizada (Product backlog) y de ejecución del propio proceso de Scrum, de manera que puedan compararlo con el desarrollo tradicional (en cascada/waterfall), comprobando cuáles son los principales beneficios de Scrum, especialmente los referidos a alineamiento con las expectativas del cliente, flexibilidad y retorno anticipado de inversión.
Todo ello construyendo un expendedor con papel, tijeras, cinta adhesiva y globos.
- Facilitador(es) del juego: explican las reglas, cronometran los tiempos de las actividades y actúan como Scrum Masters.
- Cliente(s) / Product Owners.
- Equipos de 5 a 7 personas.
- 30 minutos: priorización de la lista de objetivos (backlog). El cliente la presenta al equipo, quien estima el esfuerzo relativo de cada uno. El cliente prioriza balanceando el valor que aporta cada objetivo respecto a su esfuerzo.
- 45 minutos de ejecución del proceso de Scrum en 3 iteraciones, cada una de 15 minutos, con las siguientes actividades:
|
Minutos
|
Actividad
|
Quien
|
|
4
|
Planificación de la iteración: El cliente presenta la lista de objetivos pendientes repriorizada y con nuevos objetivos (a partir de la segunda iteración).
El equipo selecciona los objetivos a completar en la iteración y los miembros se autoasignan tareas.
|
Equipo y cliente
|
|
6
|
Ejecución de la iteración. Construcción del expendedor*.
|
Equipo
|
|
3
|
Demostración. El equipo hace una demostración de los objetivos completados*, el cliente los acepta (si cumplen sus expectativas).
|
Equipo y cliente.
|
|
3
|
Retrospectiva. Identificación de lo que ha funcionado bien y de lo qué es necesario mejorar en el proceso de trabajo.
|
Equipo
|
- 10 minutos para reflexionar una vez ha finalizado en juego.
ID |
|
Valor |
Equivalente web |
|
|
Requisitos iniciales |
||
|
1 |
Marca de cliente: El consumidor podrá ver con claridad el nombre de la marca deportiva y una foto o dibujo de temática marina desde una distancia de 3 metros. |
1000 |
Página Home |
|
2 |
Producto: El consumidor podrá recoger el producto de una cajita específica. |
900 |
Contenidos o servicios de la web |
|
3 |
Hucha: El consumidor podrá pagar el producto depositando un billete en una cajita específica. |
800 |
Módulo de pago |
|
4 |
Transporte: Un transportista (por ejemplo el propio cliente) podrá trasladar el expendedor al lugar de venta, una mesa que diste 3 metros, sin que se rompa. |
700 |
Pruebas de estrés y subida a producción. |
|
5 |
Globos: El consumidor verá en cada uno los 2 laterales del expendedor 3 globos de 40 centímetros de diámetro (6 globos en total), para dar una imagen de diversión del deporte náutico. |
300 |
Estilo de la interfase de la web. |
|
6 |
Barcos: El consumidor verá en los 2 laterales del expendedor 3 barcos de papel (6 barcos en total), para reforzar la imagen de deporte marino y hacer marketing de próximos productos. |
100 |
Promoción de próximos servicios. |
|
|
Requisitos adicionales para la segunda iteración |
|
|
|
7 |
Nuestro cliente, al ver los colores con que se está elaborando el expendedor, se da cuenta de que debería predominar el color negro, en línea con la próxima campaña de cambio de imagen corporativa en la que predomina este color. Color negro: El consumidor verá que el color negro predomina en el expendedor, en línea con la nueva imagen de marca. |
600 |
Cambios de contexto del proyecto, del mercado, entendimiento del producto por parte del cliente. |
|
8 |
Foto de experto: El consumidor verá en el expendedor una foto de un experto del deporte con un texto donde explique las excelencias del nuevo producto, para dar confianza al consumidor. |
200 |
Sección de marketing de la web. |
|
|
Requisitos adicionales para la tercera iteración |
|
|
|
9 |
El departamento de marketing de nuestro cliente ha ideado otro producto que es una variante del anterior y tiene mucho interés por saber cual de los dos se venderá más. Producto adicional: El consumidor podrá recoger otro tipo de producto de otra cajita específica. |
500 |
Nuevos servicios relevantes para la web que aparecen en medio del proyecto y que aumentan mucho su valor. |
|
10 |
Algunos consumidores han comentado que el expendedor podría ser más atractivo. Globos grandes*: El consumidor verá en cada uno de los 2 laterales del expendedor 2 globos de 80 centímetros de diámetro (4 globos en total), en lugar de 4 de los anteriores de 40 cm, para reforzar la imagen de diversión del deporte. |
150 |
Mejora del estilo de la web. Asimilable a un “capricho” tecnológico del cliente poco relevante para el producto. |
Para tener información real de la acogida de los consumidores respecto al nuevo producto de deportes marinos, así como del concepto de expendedor automático, nuestro cliente quiere hacer una prueba de concepto en tiendas escogidas para tal efecto (equivalente a una salida en beta de una web).
Para ello, cuando se haya conseguido el objetivo 4 (el cliente ha comprobado que es posible trasladar el expendedor hasta el punto de venta sin que se rompa), y si los objetivos 1, 2 y 3 también esté aceptados, cada vez que finalice una iteración (incluyendo la iteración en curso) el facilitador del juego (o el cliente) pondrá dinero de juguete en la hucha y recogerá parte de las tarjetas de productos marinos.
- Uno de los equipos NO seguirá el proceso iterativo, sino que construirá el expendedor simulando un proceso en cascada/waterfall tradicional con las siguientes fases:
|
ID
|
Fase
|
Quien
|
Entregables
|
|
1
|
Recogida de requisitos, análisis y diseño
|
JP/analista y cliente.
|
– Documentos de análisis funcional y diseño técnico.
|
|
2
|
Planificación
|
JP/analista
|
– Documento de planificación con tareas, duración y asignaciones.
|
|
3
|
Construcción y pruebas.
|
Equipo
|
– Documentación de casos de prueba con sus resultados.
|
|
4
|
Aceptación
|
JP/analista y cliente.
|
– Expendedor.
– Documento de aceptación del proyecto.
|
- El equipo se descompone en:
- Jefe de proyecto (JP) / analista. Es el único que puede preguntar y escuchar respuestas del cliente. Con la información que obtiene del cliente elabora la documentación de fase 1.
- Tester. Elabora la documentación de fase 3.
- Resto del equipo. Construye el expendedor. Ni el JP/analista ni el tester pueden participar.
- El JP/analista recibe los objetivos SIN el valor que tienen para el cliente. Por ejemplo, el cliente le entrega lista inicial de 7 objetivos desordenada.
- El tester y resto del equipo no pueden escuchar al cliente en ningún momento. Antes de empezar la fase 3 deben leer la información generada en la fase 1. Si tienen dudas sólo pueden preguntar al JP/analista, quien preguntará al cliente si es necesario.
- Las fases se ejecutan de manera secuencial. Para poder finalizar las fases 1 y 3 el cliente debe leer la documentación de la fase y aprobarla mediante firma. Notar que el cliente puede solicitar modificaciones en la documentación, por ejemplo si no está conforme con la descripción del expendedor.
- El cliente no podrá ver el expendedor hasta la fase 4 (aceptación). Deberá ser aceptado por el cliente mediante firma.
- Todo cambio debe ser escrito por el JP/analista, planificado y aprobado por el cliente mediante firma antes de iniciarse su desarrollo.
- El equipo “tradicional” recibe el requisito adicional 9 (“producto adicional”) en el mismo momento que los equipos ágiles.
- El equipo “tradicional” recibe los nuevos requisitos 7 (“color negro”) y 10 (“globos grandes”) en la fase de aceptación, dado que hasta ahora nuestro cliente sólo ha leído documentación y no ha podido ver la aplicación real funcionando. En este momento se ha dado cuenta de que estos otros objetivos también deberían estar incluidos para que la subida a producción tenga sentido para su negocio.
- El juego (construcción del expendedor por los equipos) termina cuando se llega a los 45 minutos (3 iteraciones de los equipos ágiles) o bien después de que el equipo “tradicional” haya desarrollado todos los objetivos y el expendedor haya sido aceptado por el cliente. Notar que el cliente puede solicitar cambios si el expendedor no cumple sus expectativas.
- Recordar que gana el equipo que haya aportado el máximo valor y satisfacción de las expectativas del cliente en el mínimo tiempo.
- Valor acumulado (suma de los valores de los objetivos completados y aceptados por el cliente).
- Taskboard de objetivos pendientes.
- En Scrum el alcance es variable. Dada una fecha donde es necesario entregar el resultado de un proyecto, al cliente le conviene que el equipo trabaje orientado a completar objetivos prioritarios y que sea flexible a cambios. Puede estar más que satisfecho si en la fecha de entrega del producto quedan fuera objetivos poco relevantes, o que hayan sido intercambiardos por otros más importantes.
- De manera similar, al completar objetivos por orden de prioridad y balancearlos en función de su coste de desarrollo, el cliente dispone de una mejor visión del proyecto y puede solicitar entregas anticipadas con las que comenzar a recuperar su inversión (Return of Investment, ROI).
- Las demostraciones regulares de producto final permiten que nadie se lleve a engaño respecto a la velocidad del proyecto y a los resultados (producto de que va a disponer). De manera regular los puede ir alineando con sus expectativas y también incorporar cambios de contexto que se produzcan durante el propio proyecto (introduciendo cambios en el inicio de cada iteración y replanificando los objetivos pendientes).
- Al equipo le conviene trabajar en el menor número posible de objetivos de manera simultánea (minimizar el Work In Progress, WIP), para:
- Tener más posibilidades de poder completar objetivos cada iteración.
- Respecto al modelo tradicional, permitir que el cliente haga cambios sobre objetivos futuros, dado que todavía no se ha empezado a desarrollar nada al respecto.
- Integración continua. Cada vez que el equipo finaliza un objetivo, este debe estar perfectamente integrado y probado de manera que el producto sea susceptible de ser entregado al cliente con el mínimo esfuerzo. Sería un riesgo dejar para el final de la iteración la integración de todos los objetivos desarrollados en ella, dado que podría no quedar tiempo suficiente para arreglar todos los problemas de integración.
- El XP Game, donde aparecen los objetivos de construir barcos de papel y globos.
- El Train Game, donde aparece la idea de que un equipo simule el desarrollo tradicional (en cascada/waterfall), para comparar la velocidad con que proporciona valor al cliente y qué metodología (ágil o tradicional) proporciona un producto que cumple mejor con las expectativas del cliente.
Proyectos Ágiles 
Hola, tengo una pregunta respecto a este juego. ¿El rol del Cliente debe desarrollarlo un participante o o una de las personas que organiza el juego? Lo pregunto porque si lo deserrolla uno de los participantes de cada equipo, se corre se corre el resgo de que los criterios de aceptación no sean los mismos para cada uno de los equipos.
Me gustaMe gusta
Buena observación 🙂 Existen las dos posibilidades con diferentes «learnings» para el «debrief» al final del juego:
Opción A) El rol de cliente lo desempeña la misma persona que organiza el juego. Se observará que, aún con los mismos requisitos viniendo de la misma persona, si se cambia el equipo de desarrollo el producto/proyecto resultante es bastante diferente. Es decir, es fuertemente dependiente de la experiencia y conocimientos de cada uno de sus miembros, así de cómo se relacionan entre ellos.
Opción B) El rol de cliente para cada equipo lo desempeñan diferentes organizadores del juego o personas de cada uno de los equipos. En este caso se obtendrá una diferencia de productos finales todavía mayor que en la opción A. Aquí hay un paralelismo con diferentes compañías que intentan innovar sobre el mismo tema y presentan al mercado soluciones muy diferentes.
Me gustaMe gusta
Hola, muchas gracias por tan buen material! Lo he realizado tanto con la versión original, así como solo la parte ágil. Me enrede un poco con las tarjetas de estimación porque como ya conocía la técnica de planning poker, estimamos con puntos de historia; (aunque las instrucciones decían que eran minutos); a propósito no se sesgan un poco los participantes para estimar con tiempo? Yo le adicionaría unos 5 minutos más a los sprints.
Saludos
Silvia
Me gustaMe gusta
Hola Silvia!
Es cierto que si ya conoces los puntos de historia puede parecer que trabajar con estimaciones temporales es un paso atrás. Sucede que este juego está pensado como introductorio a Scrum, con sus conceptos básicos, los puntos de historia son una técnica más avanzada. En la presentación del juego puedes explicar que esta técnica existe (o avisar de que no se va a poder utilizar en el juego para no extenderlo demasiado y utilizar otro juego para explicarla). En esta simulación se utilizan minutos para facilitar pensar a los participantes cuántos requisitos van a caber en cada Sprint (de hecho, ellos todavía no conocen su velocidad para poder planificar en puntos de historia y, como he comentado, habría demasiadas cosas para aprender [ver más abajo] si el juego también introdujese este concepto).
Los Sprints son de 10 minutos precisamente para simular la realidad: a veces el equipo no se enfoca lo suficiente en el resultado final a entregar al final del Sprint y su calidad, se pierde demasiado en seguir cada uno su plan detallado personal en lugar de trabajar en equipo y colaborar para ser más efectivos, se entregan cosas con baja calidad por que ese aseguramiento se deja al final del Sprint, etc. En este juego conscientemente haya bastantes oportunidades de que algún Sprint no salga bien (por ejemplo, que el Product Owner no acepte historias de usuarios como hechas por su baja calidad) por que ayuda a entender cuáles son las causas en un entorno simulado (mucho mejor que en la vida real). Eso sí, mejor si le pones un poco de humor en todos esos «fail fast» 😉 Por ello, es vital hacer un debrief conjunto de las cosas que han funcionado o no, en cuanto a satisfacción del Product Owner, trabajo del equipo, etc.
Me alegro de que hayas disfrutado con el juego 🙂
Xavi
Me gustaMe gusta