Hace unas semanas me propusieron preparar una formación interna en la empresa sobre Scrum, y yo encantado de hacerla acepte. Hará ya algún tiempo hice una formación al respecto, en la que utilice el sistema creado por Alexey Krivitsky Lego4Scrum y me funciono realmente bien, así que ni corto ni perezoso decidí que esta seguía siendo una fantástica forma para explicar las bondades de Scrum. Y aquí están mis reflexiones de como fue la mañana de formación.
Lego4Scrum
El proyecto de Lego4Scrum consiste en una simulación de proyecto en el que se utiliza metodología Scrum para llevarlo a cabo y que consiste en la construcción de una ciudad, utilizando las piezas de Lego para ello.
Para la realización de la simulación hace falta crear un backlog, valorarlo, realizar varios sprints con sus consiguientes preparaciones, reviews y retrospectivas. Por lo que se antoja un ejercicio muy completo.
Empezando la sesión con algo de teoría
Como ya he comentado antes, hace algún tiempo ya utilice Lego4Scrum, pero una de los puntos flojos que me comentaron al finalizar la formación, es que habían echado en falta algo de contexto previo sobre los términos y técnicas utilizadas, así que esta vez he empezado la formación con una pequeña introducción teórica con los elementos mas utilizados en Scrum. La idea es que simplemente fuese algo introductorio para que a todo el mundo le sonasen los términos de los que mas tarde hablaríamos. No quería hacerlo muy largo, pero entre las explicaciones, algún mini-juego y las preguntas que surgieron nos fuimos casi a las dos horas. A partir de ese momento, empezó lo realmente divertido.
Organización de los equipos y algo de contexto.
Para empezar con la simulación, lo primero era dividir a todos los asistentes en equipos, y que mejor forma para demostrar la auto-gestión que haciendo que ellos mismos formasen los tres equipos que eran necesarios. La cosa fue rápida, así que nos pusimos al tema muy rápidamente.
Antes les dí algunas premisas previas para empezar:
- Todos los equipos trabajan para el mismo proyecto, no están compitiendo entre ellos.
- El producto que tienen que construir es una ciudad.
- El material para construir dicha ciudad, son piezas de lego, pero también pueden usar cualquier material que tengan a mano (como Post-it o rotuladores)
- Yo tengo la última decisión sobre la ciudad. Es mi ciudad.
- Estaré involucrado en el proyecto resolviendo dudas y dando feedback.
Una cosa que no les dije es que como cliente iba a ser un poco puñetero, y que cada una de las tareas que tendrían iba a tener unos tiempos muy limitados, todo ello pensado para generar algo de estrés en proceso.
Una vez aclarados estos puntos y creados los equipos, empezamos con la simulación!
Product Backlog
El Product Backlog para la creación de la ciudad consistió en:
● Varios edificios de un piso
● Varios edificios de dos plantas
● Tienda
● Escuela
● Iglesia
● Hospital
● Guardería
● Parada de autobús
● Intersección (se puede dibujar)
● Parque (Se puede dibujar)
● Río (se puede dibujar)
● Puente
Estimación
La primera de las tareas de los equipos es estimar el coste en puntos de cada una de las tareas que hay que realizar. Para ello se utilizo la técnica «Swimlane Sizing«.
Esta técnica cosiste en crear columnas que representan el coste de las tareas y la posterior ordenación de estas tareas en cada una de las columnas. Se elige una tarea, por lo general poco costosa y se estima que tiene un coste de un punto, a partir de esa tarea base se decide el coste del resto y se colocan en cada una de las columnas.
En este punto se podría haber usado perfectamente «Scrum Pocker» pero creo que en equipos tan grandes y para la simulación esta técnica funciona mejor.
Para este ejercicio el equipo tenía 20 minutos, y lo que al principio parecía que iba a ser tiempo de sobra, al final resulto ser algo escaso. Llegaron con el tiempo justo.
Una de las claves importantes en este punto, es la capacidad del equipo para hacer las preguntas correctas para realizar una buena estimación. Yo, de una forma premeditada, les dí unas descripciones muy vagas sobre lo que quería para que tuviesen que hacer preguntas.
Al final el ejercicio fue un éxito, el equipo realizó preguntas muy acertadas buscando una mayor definición del producto y generó discusión sobre el valor de cada una de las tareas, y cuando no existía pleno acuerdo, se resolvió con votaciones.
Sprint Planning, Sprints, reviews y retrospectives
Una vez valorado el Product Backlog lo siguiente que tocaba era crear el Sprint Backlog, o lo que es lo mismo, ver cuanto esfuerzo era capaz de realizar cada uno de los equipos. Para esto los equipos tenían tres minutos por planning. El primer planning fue un desastre, pero esta es la idea del juego, demostrar como en solo tres Sprints los equipos ajustan sus estimaciones, siendo la primera un desastre y el resto cada vez mejores.
Una vez definido el trabajo a realizar en el Sprint, los equipos se ponen a ello. Siete minutos por Sprint. Aquí cada uno de los equipos trabaja en sus tareas, pero siempre teniendo en mente que han de avanzar juntos, trabajando sobre el mismo proyecto.
El primer Sprint, como era de suponer fue un poco desastre (al igual que la planificación), cada uno de los equipos trabajó sin comunicarse con el resto, creando los edificios con formas muy distintas entre ellas (edificios planos vs. edificios mas «tridimensionales»), con tamaños desproporcionados y con muy poco detalle en las tareas.
A consecuencia de ello, muchas (la mayoría) de las tareas que fueron planeadas para el Sprint 1 fueron rechazadas y se movieron de nuevo al Backlog, por lo que tuvieron que ser asumidas en el siguiente Sprint.
La retrospectiva (dos minutos) parece que les sirvió para mejorar mucho los procesos, ya que a partir del segundo Sprint todo fluyo de una forma realmente buena.
El las siguientes iteraciones los equipos mejoraron cada una de las valoraciones del Sprint y la ejecución de las tareas, cumpliendo sobradamente con el objetivo del proyecto de construcción de ciudad, creando edificios con una linea y tamaños similares y con un detalle mucho mayor (fijaos en el colegio con pista de fútbol y parking).
En resumen, creo que fue una sesión muy interesante en la que se aclararon muchos conceptos sobre Scrum y como aplicarlos en proyectos reales (esto da para otro post), y gracias a Scrum4Lego se pudo aplicar todo lo aprendido en una simulación muy divertida. Totalmente recomendable, ¡seguro que volveré a repetir!
Enlaces de interés