Categoría: simulaciones y juegos

Abecedario y Números – Simulación de organizaciones y multitarea

Para ser más eficientes, es necesario hacer un rediseño organizativo que reduzca las dependencias entre grupos y compactar la cadena de valor, con lo cual se reducen colas, multitarea y Work In Progress en la empresa. Es mucho mejor conectar grupos y personas que coordinarlos.

Como consecuencia de esto, la visión es crear equipos más pequeños y autónomos, que contengan todas las capacidades necesarias (skills de personas) para resolver por completo un objetivo.

Este juego simula una organización y personas trabajando en varios proyectos o tareas de manera simultánea, evidenciando el empeoramiento de tiempos de finalización, predictibilidad y calidad por el hecho de tener una red de dependencias demasiado grande, lo cual lleva a mucha gestión de coordinación y multitarea. La duración del juego es de 30 minutos.

El juego consta de 4 Simulaciones:

·         S1 – Una organización en que cada persona colabora con otras en varios proyectos.

·         S2 – Una organización con equipos de trabajo dedicados a ejecutar proyectos.

·         S3 – Una persona ejecutando dos tareas simultáneamente.

·         S4 – Una persona ejecutando dos tareas secuencialmente.

Puedes bajarte este juego en formato pdf a partir del siguiente enlace.

descargar

Material

    • Proyector

timer

    • Folios y bolígrafos
  • Mesas enfrentadas en grupos de 8 personas.

Simulaciones

S1 – Una organización en que cada persona colabora con otras en varios proyectos

Reglas:

  • Cada persona coge un folio en blanco, del cual será “propietario”. Unas personas comenzarán a escribir en su folio el Abecedario y otras Números (del 1 al 27). La distribución será la siguiente:

  • Cada persona escribe 3 letras (ABC) o tres números (123) e intercambia su folio con otra persona, que escribirá los 3 siguientes y los retornará a su propietario para que siga con otros 3. Se intercambian los Números con la persona de delante y el Abecedario con la persona en dos posiciones hacia la derecha:

8personas-numeros-letras-intercambio

    • Notar que en un folio acabarán escritos sólo el abecedario o números.
    • Cada “propietario”, cuando se haya acabado de escribir todos los números o el abecedario, apuntará el tiempo que se ha dedicado según indique el temporizador.
  • Al acabar todas las personas, el facilitador toma las siguientes métricas:
      • Registra en un flipchart un histograma con los tiempos que han dedicado todas las personas.
    • Hace de “cliente”: revisa todos los folios y contabiliza tanto errores (faltan letras, …) como las letras o números que no le gustan por que no entiende la caligrafía. Apunta el número de errores en el flipchart.

S2 – Una organización con equipos de trabajo dedicados a ejecutar proyectos

  • Se repite la simulación S1, intercambiando los folios sólo con la persona de delante.

S3 – Una persona ejecutando dos tareas simultáneamente.

  • Se repite la simulación S3, cada persona consigo misma, escribiendo letras y números de 3 en 3, en la misma cara y rotando el papel. Se apunta el tiempo cuando se acaba de escribir todo.

 

S4 – Una persona ejecutando dos tareas secuencialmente.

    • Cada persona repite la simulación S4 consigo misma.
        • Primero se completa todo el Abecedario.
      • Después se completan todos los números.
  • Se apunta el tiempo cuando se acaba de escribir todo.

Histogramas

histogramas

    • Cuantas más personas hay colaborando simultáneamente en diferentes proyectos, estarán más ocupadas pero la productividad será menor. La malla de relaciones es grande, con lo que se necesitan más sincronizaciones. Las colas, tiempos de espera y cambios de contexto son grandes y crean dependencias artificiales entre proyectos que no tienen nada que ver.
    • Un proyecto tarda menos si se crea un equipo de personas concentrada en acabarlo, al haber interacciones más rápidas y menos cambios de contexto.
    • Poner el doble de personas no hace que los proyectos acaben en la mitad de tiempo (comparar S2 con S3).
  • Cuando hay multitarea …
      • Hay menor predictibilidad, la varianza respecto a cuándo se acabará es más grande.
      • Se producen más errores / menor calidad, por perderse información en los cambios de contexto.
    • Y, lo que es peor: se tarda más, el Time-To-Market empeora, aunque la intención de hacer multitarea (o tener a muchas personas ocupadas, trabajando en muchos proyectos mallados) era tardar menos. La productividad es menor debido a los cambios de contexto, necesidad de sincronización, colas.

 multitarea

Conclusiones / Debrief

    • Hacer un rediseño organizativo que reduzca las dependencias entre grupos/departamentos y compactar la cadena de valor dentro de equipos/grupos más pequeños (creando mayor autonomía), con lo cual se reducen colas, multitarea y Work In Progress en la empresa. Es mucho mejor conectar grupos y personas que coordinarlos. Para ello hay que crear equipos pequeños autónomos, con todas las capacidades necesarias para resolver problemas, co-localizados  y enfocados a cerrar temas (aspectos que forman parte de las bases de Scrum) que equipos muy grandes, muy distribuidos y colaborando en muchos proyectos simultáneamente.
  • Cerrar temas, hacer una cosa tras otra. No abrirse más frentes de los necesarios por que otros objetivos se hayan “bloqueado” por dependencias de otras personas o áreas. Como diría Ángel Medinilla, “un bloqueo es una emergencia nacional”, se tiene que hacer todo lo que se pueda para eliminar un bloqueo, no asumirlo como “normal” (notar que todo esto en línea de la mejora continua y de la disminución de WIP y de colas en Kanban).
  • Reducir el WIP (Work In Progress), tanto a nivel personal como entre personas de un equipo. Cada persona / equipo no debería trabajar en más de 2-3 tareas en paralelo. Por encima de esto la productividad baja notablemente.

Puedes bajarte este juego en formato pdf a partir del siguiente enlace.

descargar

Para cualquier mejora en el juego, no dudéis en enviar vuestros comentarios a la dirección xavier PUNTO albaladejo ARROBA gmail PUNTO org

Reconocimientos

Agradecer a Teocé el dar a conocer las simulaciones S3 y S4, que han llevado a la extensión del juego para incorporar la S1 y S2.

Artículos relacionados

El expendedor – Juego de simulación de Scrum

“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.

El juego también permite entender diversos conceptos que facilitan el desarrollo ágil: alcance variable, minimizar el número de objetivos en curso (WIP), integración continua de componentes, etc. Para ello, se incluye como factores de complejidad diversos cambios de objetivos durante el proyecto y un problema tecnológico.

Todo ello construyendo un expendedor con papel, tijeras, cinta adhesiva y globos.

expendedor-simulacion-juego-scrum-1
Puedes bajarte las reglas del juego y las tarjetas de objetivos de cada equipo a partir del siguiente enlace. El tamaño del fichero es unos 400 Kb.
descargar-material-juego-simulacion-Scrum

El contexto del juego es el siguiente: nuestro cliente, una gran marca deportiva, quiere lanzar un producto para deportes marinos inexistente en el mercado. Con el fin de dar una mayor imagen de innovación, este producto se venderá mediante un expendedor automático.
Nuestra visión será: Construir un expendedor automático de un producto deportivo.
En el juego participan dos tipos de equipo: un equipo que ejecuta un proceso ágil y otro equipo que NO seguirá el proceso iterativo, sino que construirá el expendedor simulando un proceso en cascada/waterfall tradicional.
La duración del juego es de 75 minutos. Gana el equipo que haya aportado el máximo valor y satisfacción de las expectativas del cliente en el mínimo tiempo.
Roles en el juego
 
Actividades del juego
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
*Definición de hecho (DoD): el objetivo ha sido construido y preparado para ser entregado al consumidor (no queda nada pendiente respecto a ese objetivo y ya está integrado en el expendedor), documentado (con el detalle adicional proporcionado por el cliente y el que sea necesario para facilitar su futuro mantenimiento) y probado (cumple los requisitos que proporcionó el cliente).
 
  • 10 minutos para reflexionar una vez ha finalizado en juego.
 
 
Lista de objetivos/requisitos (product backlog)
Los objetivos/requisitos que debe cumplir el expendedor son los siguientes:
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.
 
Retorno de Inversión (ROI) anticipado
Uno de los mensajes que se quiere transmitir en el juego es que antes de que el proyecto esté finalizado es posible comenzar a recuperar la inversión o obtener feedback de un grupo de clientes o de usuarios beta.

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.

 
expendedor-simulacion-juego-scrum
Comparativa de desarrollo ágil con desarrollo tradicional
Reglas para el equipo “tradicional”
  • 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.
 
Reglas para el facilitador del juego
  • 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.
 
Métricas
En cada iteración el facilitador del juego elabora las siguientes gráficas para cada equipo:
  • Valor acumulado (suma de los valores de los objetivos completados y aceptados por el cliente).
  • Taskboard de objetivos pendientes.
 
Aspectos sobre los que reflexionar una vez finalizado en juego / Debrief
  • 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.
Puedes bajarte las reglas del juego y las tarjetas de objetivos de cada equipo a partir del siguiente enlace. El tamaño del fichero es unos 400 Kb.
descargar-material-juego-simulacion-Scrum
Para cualquier mejora en el juego, no dudéis en enviar vuestros comentarios a la dirección contribuir (arroba) proyectosagiles (punto) org
 
Reconocimientos
Este juego obtiene parte de su concepto de los siguientes juegos:
  • 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.
 

Artículos relacionados