Mi experiencia enseñando Scrum con #Lego4Scrum

1. Introducción

Recientemente fui invitado a dar unas clases sobre metodologías ágiles y Scrum en el Master de Analítica de Negocios y Grandes Volúmenes de Datos en la Universidad de Alcalá. Se trataba de una asignatura “lateral” dentro del currículo del master, pero ya sabemos la importancia que tienen hoy en día las metodologías ágiles en los entornos innovadores, y el Big Data, casi por definición, podría considerarse altamente innovador.

Si has usado metodologías ágiles o has leído algo acerca de ella, habrás podido observar que los manuales “oficiales” o guías de referencias tienen una longitud muy limitada, ya que no son pesados modelos teóricos sino prácticos. En la “Scrum Guide” (guía oficial del de Scrum) podemos encontrar este párrafo:

“Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known.”

Es decir, se trata de algo que se adquiere por la experiencia y no por mucho que estudies un modelo teórico o un manual, sobre todo si éste es escaso, podrás acumular una destreza suficiente como para aplicarlo correctamente.

Lo ideal para aprender Scrum es vivirlo: trabajar en un proyecto con otra gente más experimentada y que practiquen Scrum o el agilismo correctamente. Esto es una de las cosas que hacemos en Autentia cuando vamos a trabajar en departamentos de desarrollo (y no tan desarrollo) in-situ para ayudarles en sus procesos de transformación digital… Pero en una clase con una unas horas limitadas y un temario establecido es algo muy complicado de transmitir.

¿Cómo enseñar Scrum en una clase? Intentando “simular” un proyecto real de forma práctica en clase. Aquí es donde, a partir de juegos como #lego4Scrum, se puede hacer una especie de “juego de rol” o simulación de la vida real en el día a día de aplicación de Scrum. De este modo los alumnos pueden experimentar y sobre todo interiorizar situaciones que surgen en la aplicación de Scrum de un modo mucho más efectivo que atender a una clase de teoría.

2. Lego4Scrum

Si visitas páginas de coaches especializados en metodologías ágiles, ves fotos por internet o atiendes un poco en Twitter, habrás visto que de vez en cuando aparecen grupos de personas adultas jugando como niños con bloques de plástico (Lego) construyendo producto con metodologías ágiles (Scrum principalmente). Me pareció una idea curiosa en la que profundizar para evaluar si lo introducía en mis clases de la Universidad de Alcalá.

2.1. El libro

Buscando un poco por Internet me topé con la guía más o menos “oficial” de este tipo de técnicas, o al menos de un autor (Alexey Krivitsky) que tiene un manual sobre cómo llevar a cabo la simulación de forma completa y sin mucho que pensar para los profesores:

Como breve reseña del libro te diré que no me ha gustado mucho aunque sí que me ha ayudado claramente a hacer la sesión. Se podría contar todo lo que hace en muchas menos hojas y de forma esquemática (como voy a hacer yo en este post): se pierde en demasiadas justificaciones y no me parece que esté bien estructurado. No obstante, si quieres montar una sesión de este tipo y no tienes quien te enseñe, deberías leerlo.

Voy a explicarte cómo dí yo la clase. Es la primera vez que lo hacía y hay un amplio margen de mejora. Si tengo otras oportunidades en el futuro seguro que lo haré mejor.

2.2. Conceptos previos a enseñar: Scrum básico y LeSS

En mi caso celebré la simulación en la tercera sesión de las clases. Previamente había establecido un marco teórico sobre Scrum y otras metodologías ágiles, contando además con la explicación pormenorizada de los roles, eventos y artefactos de Scrum. Aquí mi primer fallo: debería haber impartido la clase detallada de Scrum con posterioridad a la práctica. Simplemente con unas nociones básicas para el juego habría sido suficiente y los alumnos habrían entendido mejor los pormenores de Scrum después de “vivirlo”.

También es necesario explicar un poco de escalado de Scrum. En el caso del libro que te recomiendo usan LeSS. No lo había hecho en las clases anteriores, pero en unos 5 o 10 minutos se lo expliqué sobre la pizarra. No hay problema, se aprende según se va jugando: el profesor va haciendo de Scrum Master también y va explicando paso a paso lo que hay que hacer: “ahora haremos el sprint planning inicial”; “vamos a hacer la estimación”…

2.3. Material Necesario

Hace falta un pequeño presupuesto de material para hacer la simulación, pero nada exagerado:

• Piezas de Lego (o bloques de plástico equivalentes). Yo utilicé unos de marca blanca compatibles ya que cuestan la mitad ?. En el libro oficial indican que con 1.000 piezas para 3 grupos es suficiente, yo usé más y sobraron. Al final los alumnos se adaptan a lo que les proporciones.
• Cartulinas tamaño A0 o similar: servirá de base de la ciudad y para hacer un Kanban y gráficos burn-down. Con 2 cartulinas por equipo son suficientes.
• Rotuladores de colores para que los equipos puedan pintar carreteras, parques… o actualizar el gráfico burn down.
• Post-it (etiquetas adhesivas) de colores para llevar las historias de forma manual a lo largo de los kanban.

3. La simulación con Lego4Scrum

3.1. La historia

El papel del guía de la simulación es muy importante ya que tiene que crear un ambiente en el que los alumnos se sientan motivados, y esto es responsabilidad tanto de la historia ideada como de la capacidad “teatral” del profesor que actúa como facilitador de la simulación. Es importante que sea capaz de transmitir la «visión» del producto

En mi caso me decidí por la creación de una nueva ciudad en un planeta diferente a la tierra donde las élites tecnológicas de Silicon Valley quieren establecer una nueva civilización bajo sus reglas.

3.2. La Conceptualización de historias de usuario

Una de las misiones de este juego es que los participantes entiendan también el papel que juegan otros roles en Scrum. Por tanto también tendrán que hacer de Product Owner en el sentido de que van a experimentar cómo es la conceptualización de un producto para obtener historias de usuario.

Para ello se siguen estos pasos para determinar:

• Roles de habitantes que puede haber en la ciudad: trabajadores, personal de servicio, inversores.
• Epicas (necesidades genéricas): transporte, salud, diversión… serán las épicas
• Historias de Usuario: que hacen realidad esas épicas: para salud hacen falta hospitales; para ocio hacen falta cines….

Con esto pueden ver cómo haciendo una descomposición adecuada es posible usar las historias de usuario para determinar las funcionalidades de los productos. Con 6 historias por grupo suele ser suficiente, ya que aunque se planifican 3 sprints luego se ejecutan realmente 2.

Esta parte resulta muy divertida y didáctica, al menos bajo mi punto de vista… es una buena oportunidad para que todos los alumnos participen con un particular “brain-storming”.

3.3. Priorización: clasificación en releases o Sprint

Se trazan 2 líneas horizontales para crear 3 sprints de clasificación:

• el superior es la Release 1 o MVP;
• luego la Release 2 de mejora del confort.
• la Release 3 para el despegue de la ciudad como gran urbe.

Una vez se tienen las historias se le piden a algunos representantes de cada grupo que salgan a la pizarra y prioricen las historias de usuario, colocando las más prioritarias en la Release 1, luego en Release 2 y luego Release 3. Como consecuencia las carreteras o los hospitales suelen estar en Release 1, mientras que el cine en release 2 o 3.

Así han podido experimentar cómo hacer una partición por prioridades y releases de las características que han pensado para la ciudad. Podrán ver que con la Release 1 se puede comenzar a vivir en la ciudad, aunque en la Release 2 se verá mejorada y pasará a un estado ideal en la Release 3. El profesor les explica que la partición que han hecho para la Release 2 y 3 se podrá modificar cuando se aborden sendos sprint planning.

3.4. Estimación

Aunque se han explicado los puntos de historia en teoría, hasta que no se usan no se pueden entender bien. Este es el momento en que los alumnos pueden empezar a usarlos.

Se utiliza triangulación para hacerlo: se trazan varias columnas en la pizarra para clasificar las historias de 1, 2, 3 5 y 8 puntos. Se toma la primera historia: “hospital” (por ejemplo) y se pregunta a la clase: “A la de 3: ¿Cuántos puntos de esfuerzo le damos al hospital?… ¡Uno, dos y tres!”. Los alumnos levantan las cartas (o en su defecto las manos).

En esta primera estimación las puntuaciones son variopintas: 1 punto, 3, 8… Es lo que se busca. El profesor comienza a preguntar “¿Por qué has elegido un 2?” Los alumnos tiene que justificar su respuesta. Con este diálogo van saliendo justificaciones que dan pie a repetir la votación. Suele haber algo más de homogeneidad, pero todavía está lejos. El Profesor puede decir “Bueno, vamos a poner esta en el 5 porque hay otras más grandes ¿verdad?”

La siguiente historia a estimar va mejor, porque los alumnos lo comparan con el hospital (hacen triangulación), aunque siempre hay disidentes. Como se haría en el mundo real, se debe volver a preguntar a los extremos por qué han tomado esas decisiones y negociar.

Con el paso de las estimaciones cada vez son más homogéneas y rápidas… Los alumnos han aprendido a estimar. Objetivo cumplido.

Algo interesante es que en las estimaciones comienzan a ver forzada la necesidad de una definción mayor, y son ellos mismos los que preguntan al profesor que actúa de Product Owner: “¿Cómo tiene que ser el cine?¿Cuántas alturas?¿Cuántas puertas tiene?”. Así se van adjuntando requisitos en el mismo post-it que tienen que cumplir las historias.

3.5. Sprint planning

Una vez está todo estimado y clasificado en releases se pasa al Sprint planning de la Release 1. Se repasa la clasificación en releases teniendo en cuenta ahora las estimaciones.

Se invita a unos representantes de los equipos a salir a la pizarra y tomar del Sprint Backlog general las historias que van a hacer cada uno de los grupos en sus sprint particulares. Usan los puntos de esfuerzo para estimar que todos se lleven lo mismo.

Sprint planning particular
Esto es algo que al final no hicimos, pero que podría ser conveniente como marca LeSS. La verdad es que con pocas historias y con una dificultad relativa (son piezas de Lego) quizá sea exagerado.

Los alumnos toman los post-it del backlog de sprint general y lo pegan en sus Kanban particulares. Cuentan los puntos de historia y preparan los gráficos burn-down. para comenzar la simulación.

3.6. La ejecución de los Sprints individuales.

Durante 7 minutos los equipos tienen tiempo para trabajar en su sprint particular. Es importante que uses un cronómetro con sonido en el proyector para que todos sean conscientes del tiempo que tienen.

Tienen que ir actualizando el Kanban según van acometiendo las historias: To do; in progress; done. También van actualizando el burn-down chart, cuyo eje horizontal está dividido en minutos: si acaban una historia en el minuto 3, bajan los puntos en el minuto 3 del burn-down.

Pasados los 7 minutos suena la alarma y todos paran de trabajar. Es el momento de la demostración del trabajo realizado.

3.7. La revisión de Sprint

Aquí es muy importante la labor “teatral” del profesor, que tiene que ponerse en la piel del Product Owner e intentar sacar fallos de forma creativa par que los alumnos entiendan qué no han hecho bien.

Suele ser común que los equipos están tan centrados en sus sprints particulares que olvidan que están haciendo un producto conjunto por lo que no tienen tiempo de integrarlo: el producto no existe al final del sprint.
Luego suelen surgir otra clase de problemas como: edificios de tamaño diferente relativo; historias que se deberían haber replicado en todos los barrios; falta de conexión entre las diferentes partes… En definitiva, un catálogo de problemas a resolver.

Si actúas como profesor – Product Owner, sé didáctico, pero a la vez serio: haz que sean conscientes de que se está construyendo un proyecto en el que hay inversores, recursos y dinero apostando por él, y que Scrum, aunque más liviano que otras metodologías, no es por ello menos comprometido.

Se revisa el Sprint backlog que se tenía de la Release 1, dando como válidas algunas historias pero rechazando otras y añadiendo nuevas historias (o bugs) al Product Backlog para corregir las deficiencias y ausencias que había en la planificación del primer Sprint. Esto también se puede hacer en la planificación del Sprint de Release 2, como el profesor estime.

Adicionalmente se puede echar un vistazo a los paneles burn-down de cada uno de los equipos y hacer una interpretación de los mismos:

• Los que han mantenido la gráfica horizontal y han acabado todo al final: demasiado WIP…
• Los que se han quedado cortos y han acabado el trabajo a mitad de sprint: poco trabajo previsto en el sprint.
• Bajadas demasiado abruptas: historias necesitan estar mejor divididas.

También se realiza la cuenta de los puntos que se previeron realizar (explicar compromiso vs previsión) en el sprint y los que realmente se han presentado y los que realmente el Product Owner ha dado como válidos. En este punto los alumnos pueden ver con cifras el volumen de su “fracaso”.

Siempre es papel del profesor motivar y animar, calmando a los participantes si se toman a mal la revisión. Tienen que entender que la calidad es algo intrínseco a Scrum y otras metodologías ágiles, y que deben aprovechar la oportunidad de mejora que ofrecen la retrospectiva y los métodos iterativos e incrementales.

3.8. Retrospectiva General

Una vez realizada la primera revisión, que generalmente pone de relieve un desastre en la primera iteración, se pasa a hacer una retrospectiva general para poner en común los problemas que han existido y ajustar los equipos para mejorar en el siguiente sprint.

Optamos por la típica retrospectiva de “estrella de mar”, en la que cada participante, usando post-it expresó qué conceptos habría que revisar, mejorar, dejar de hacer o impulsar.

En este punto se ponen problemas evidentes de relieve, todos enfocados a la mejora del proceso de trabajo para obtener un producto mejor. Se consigue también el enfoque en los problemas por parte de todos, y se hace una lista con las soluciones a adoptar: nombrar un representante de equipo que visite a los otros durante el sprint; más comunicación con el Product Owner; dejar el último minuto para la integración final; mejor reparto de tareas…

Bien es cierto que con LeSS se deben hacer dos retrospectivas, la general y la específica de cada equipo. Quizá la segunda, la específica, sea algo redundante para este nivel de aprendizaje, pero mejor dejarlo a criterio del profesor.

3.9. Continuando con el Sprint 2

Después del más que presumible fracaso del Sprint 1 (es necesario que fracase para que los alumnos aprendan mejor), seguro que todos están alineados con el objetivo de crear un producto conjunto que satisfaga al cliente.

Durante este último sprint (no suele ser necesario hacer el tercero por no aportar demasiado a la formación), el objetivo será ver cómo los equipos adaptan su forma de trabajar para lograr un mejor resultado, y cómo Scrum (y cualquier metodología iterativa e incremental) permite recuperarnos de los problemas en poco tiempo y con pocos recursos.

Comienza una nueva iteración.

3.10. Planificación del Sprint 2

Una vez se tiene el Backlog de Producto con las historias previstas para la Release 2, se le han añadido:

• las historias rechazadas de la Release 1,
• las historias inacabadas en la Release 1,
• los bugs que corrigen historias incorrectas en la Release 1 (si se elige esta estrategia),
• historias nuevas que han surgido al hacer la revisión de Release 1, pero que no se tuvieron en cuenta en la concepción del producto.

Además se incluye la “velocidad del equipo” que asignaron al sprint Release 1 y la que tuvieron realmente, para que sean conscientes de cuántas historias pueden abordar.

3.11. Ejecución del Sprint 2

A partir de este punto de sigue de nuevo la mecánica que se siguió en el Sprint 1 pero ya conociendo el procedimiento en la práctica y siendo conscientes de todos los problemas que surgían y que tienen que solucionar para lograr un solo producto.

En este nuevo Sprint, además de desarrollar historias de usuario previstas en la planificación, se comunican entre ellos, establecen criterios únicos y están atentos al tiempo restante para realizar una última fase de integración que esta vez sí les permita entregar un solo producto completo para la revisión por el Product Owner.

Pasados los 7 minutos, y tras unas cuantas carreras con los tableros de cartulina para entregarlos, los alumnos logran presentar una versión utilizable del Producto con un “incremento” suficiente como para que comience a desarrollarse la vida en ella: muy lejos de la primera versión fallida.

El Profesor que actúa de Product-Owner en este momento puede hacer una brevísima revisión del producto, pero sobre todo su misión será la de recordarles las fases por las que han pasado y cómo el uso de Scrum les ha ayudado a entregar un producto que comienza a ser válido, y cómo, si siguiera la simulación podrían ir mejorándolo. Por ejemplo:

• “En el primer Sprint hemos cometido fallos porque no teníamos el conocimiento completo: había historias definidas de forma insuficiente”
• “Luego no hemos sabido actuar como trabajadores de un mismo producto por lo que no fuimos capaces de entregar el producto en la Release 1”
• “Imaginaos que hubiésemos usado Waterfall y hubiésemos gastado todo el tiempo y recursos de los 3 sprints sin hace demo ni consultar al Producto Owner: habría sido un fracaso completo”
• “Hemos realizado una retrospectiva para ajustar nuestro modo de trabajo a las circunstancias; también hemos introducido nuevas historias por carencias que existían”.
• “En el Sprint 2 hemos estado más centrados en el producto y motivados, y el resultado ha sido muy positivo”…

En este punto en el manual de #Lego4Scrum indica que no es necesario seguir con el juego ya que los alumnos han aprendido la lección y sería realizar otra iteración en balde: seguro que hay otros temas que tratar.

4. Últimos consejos

• La figura del profesor / facilitador es fundamental en este juego. Debe meterse dentro de su papel y “actuar” para que todo el mundo se sienta dentro de la atmósfera de la simulación, incluso los más escépticos (hay gente que puede sentirse ofendida por hacerle jugar con cosas de niños).
• El profesor / facilitador deberá ser creativo para adaptarse a los cambios que los alumnos le van a plantear: imagina que hacen la ciudad al primer intento tal y como pensabas que estaría bien… te tocará “inventarte” algo para rechazar historias de usuario… u ocultar cosas adrede para provocar el fallo.
• Controla el tiempo a raja-tabla. Es muy fácil irse de horas y que acabe ocupando el doble de tiempo previsto o más: ten a mano un cronómetro, si es visible por todos mejor, y marca los tiempos constantemente: “Tenéis 2 minutos para priorizar las tareas”, “¡os quedan 25 segundos!”.
• Revisa los elementos claves de la simulación y sé celoso con que se cumplan los elementos básicos: recuerda que es la primera vez que experimentan realmente con Scrum así que es importante que la primera vez se aprenda “bien”.
• Mantén siempre un ambiente de diversión, pero también de respeto por los demás y por el método.
  Pon de relieve los logros de Scrum para lograr los objetivos marcados: “gracias a la retrospectiva hemos sido capaces de lograr un consenso para trabajar mejor”; “como hemos usado sprints cortos, en el siguiente lo podremos arreglar con un coste menor”.

5. Resumen final

Después de esta primer experiencia usando Lego4Scrum, y analizando el poso que han dejado en los alumnos las clases posteriores pienso que su aplicación ha sido bastante positiva, tanto en el ambiente de cohesión entre los alumnos como sobre todo en la adquisición de conocimiento respecto del método de Scrum y la utilidad de las metodologías ágiles.

Claro está que su aplicación debe darse en circunstancias muy específicas, como disponer de un tiempo limitado para explicar metodologías ágiles (en este caso Scrum) y contar con un grupo con nula o poca experiencia en este campo.

Obviamente este tipo de simulaciones no puede sustituir a una experiencia real de meses / años trabajando en un proyecto con gente que aplica Scrum de forma correcta, pero sí que supera ampliamente a una formación simplemente teórica. Si tengo la oportunidad en el futuro lo volveré a utilizar.