Enseñando Scrum de una forma divertida
La semana pasada tuve la oportunidad de impartir un taller de Scrum en AdejeTec 2012, no es el tipo de formación al que estoy acostumbrado, pero utilizando la experiencia de algunos gurús, mi propia experiencia en el uso de Scrum día a día y poniéndole un poco de empeño, parece que salió bastante bien. Por esta razón voy a explicar que es lo que hice, así podrás decirme si se puede mejorar de alguna manera o tal vez quieras organizar tu propio taller. Te aseguro que es aun más divertido de lo que yo pensaba.
Tenía libertad total para el desarrollo del taller, por lo que no quería que fuese una clase magistral en la que yo hablo 2 horas y los asistentes se duermen al fresco del aire acondicionado. Desde el principio quería que fuese una actividad en la que todo el mundo participase y los conceptos fuesen surgiendo durante la ejecución, de esta forma se entienden mucho mejor.
Como es inevitable, comencé con una pequeña presentación, al fin y al cabo, ninguno de los asistentes conocía lo que era Scrum. Eso sí, la intente hacer en 15 minutos o menos, porque yo soy de esas personas que cree que la teoría de Scrum no es para nada compleja, en realidad es muy sencilla. Lo realmente complicado es llevarla a la práctica.
Durante la presentación se explican los roles involucrados en Scrum, las actividades y "artefactos" de Scrum y algunos consejos relevantes así como una breve bibliografía. De esta manera se rompe un poco el hielo, los asistentes hacen unas cuantas preguntas y se ponen en situación, facilitando el taller posterior.
La verdad es que aunque me encantan los juegos para mostrar conceptos, mi favorito es The Marshmallow Challenge, en mis fuentes habituales, como TastyCupcakes, no encontraba nada que me convenciera. Así que tocó googlear un poco y llegué a dos páginas que me parecieron muy interesantes.
La idea de Michael Sahota de utilizar las tarjetas de XP Game como historias de usuarios me pareció fantástica, porque en 2 horas hay muy poco tiempo para que los propios asistentes escriban sus historias de usuario. Y por otra parte las historias descritas en XP Game son increíblemente simples y divertidas, se trata de actividades muy sencillas, o quizás no tanto, como inflar 10 globos de un determinado tamaño o hacer 5 barquitos de papel. Además ya tienen un valor de negocio asignado que me parece bastante apropiado porque hace plantearse a los jugadores que historias son más convenientes y cuales son muy complejas para el valor de negocio que aportan.
Como al taller solo fueron 7 personas tuve la oportunidad de hacer un único equipo y estar con ellos todo el rato, creo que esto influyó en que fuese tan bien. Así que después de entregar las tarjetas de los roles al azar, y tuviésemos nuestro Scrum Master, el Product Owner y los miembros del Equipo, les entregué el taco de tarjetas con las historias de usuarios. Durante los primeros 20 minutos crearon un Product Backlog priorizado y estimado, y prepararon el primer Sprint.
Se pusieron manos a la obra, y cuando acabaron se dieron cuenta que la estimación no había sido tan buena como creían. Cada sprint lo realicé de 4 minutos, tiempo que creo que es bastante bueno, ni mucho ni poco. Algunas tareas habían llevado mucho más de lo que creían y otras menos, pero no lograron completar tantas tarjetas como habían estimado.
Ningún problema, durante 10 minutos se planificó el segundo sprint y posteriormente lo ejecutaron durante 4 minutos. Como muchos habréis adivinado, en esta ocasión acertaron mucho más, ya tenían cierta experiencia. En el tercer sprint fue mucho mejor aún, y ellos mismos se iban dando cuenta de estos detalles y haciendo preguntas sobre la organización del backlog, el uso de prototipos o spikes para estimar en la siguiente iteración, auto-organización del equipo, etc.
Al final los tiempo elegidos estuvieron muy bien, 20 minutos para la planificación inicial, 10 minutos para cada planificación de sprint posterior, 10 minutos para cada revisión de sprint y 4 minutos para ejecutar cada sprint. Parece que puede sobrar mucho tiempo, pero no es así, primero necesitas dejar tiempo para una retrospectiva, y segundo necesitas responder dudas sobre el proceso que les van surgiendo poco a poco.
Conclusiones
Las conclusiones en un evento de este tipo siempre son subjetivas, pero creo que son unas buenas ideas de partida para mejorar la experiencia.
No lo tengo claro, pero quizás vosotros me podais dar una segunda opinión respecto a algunos temas.
Tenía libertad total para el desarrollo del taller, por lo que no quería que fuese una clase magistral en la que yo hablo 2 horas y los asistentes se duermen al fresco del aire acondicionado. Desde el principio quería que fuese una actividad en la que todo el mundo participase y los conceptos fuesen surgiendo durante la ejecución, de esta forma se entienden mucho mejor.
Como es inevitable, comencé con una pequeña presentación, al fin y al cabo, ninguno de los asistentes conocía lo que era Scrum. Eso sí, la intente hacer en 15 minutos o menos, porque yo soy de esas personas que cree que la teoría de Scrum no es para nada compleja, en realidad es muy sencilla. Lo realmente complicado es llevarla a la práctica.
Durante la presentación se explican los roles involucrados en Scrum, las actividades y "artefactos" de Scrum y algunos consejos relevantes así como una breve bibliografía. De esta manera se rompe un poco el hielo, los asistentes hacen unas cuantas preguntas y se ponen en situación, facilitando el taller posterior.
La verdad es que aunque me encantan los juegos para mostrar conceptos, mi favorito es The Marshmallow Challenge, en mis fuentes habituales, como TastyCupcakes, no encontraba nada que me convenciera. Así que tocó googlear un poco y llegué a dos páginas que me parecieron muy interesantes.
- Play the Scrum Simulation (based on XP Game) de Michael Sahota
- Training excercise: Scrum simulation de Karen Graves
La idea de Michael Sahota de utilizar las tarjetas de XP Game como historias de usuarios me pareció fantástica, porque en 2 horas hay muy poco tiempo para que los propios asistentes escriban sus historias de usuario. Y por otra parte las historias descritas en XP Game son increíblemente simples y divertidas, se trata de actividades muy sencillas, o quizás no tanto, como inflar 10 globos de un determinado tamaño o hacer 5 barquitos de papel. Además ya tienen un valor de negocio asignado que me parece bastante apropiado porque hace plantearse a los jugadores que historias son más convenientes y cuales son muy complejas para el valor de negocio que aportan.
 |
| Historias de usuario y tarjetas de roles utilizadas |
Se pusieron manos a la obra, y cuando acabaron se dieron cuenta que la estimación no había sido tan buena como creían. Cada sprint lo realicé de 4 minutos, tiempo que creo que es bastante bueno, ni mucho ni poco. Algunas tareas habían llevado mucho más de lo que creían y otras menos, pero no lograron completar tantas tarjetas como habían estimado.
 |
| El equipo trabajando al 100% para completar su sprint |
Al final los tiempo elegidos estuvieron muy bien, 20 minutos para la planificación inicial, 10 minutos para cada planificación de sprint posterior, 10 minutos para cada revisión de sprint y 4 minutos para ejecutar cada sprint. Parece que puede sobrar mucho tiempo, pero no es así, primero necesitas dejar tiempo para una retrospectiva, y segundo necesitas responder dudas sobre el proceso que les van surgiendo poco a poco.
Conclusiones
Las conclusiones en un evento de este tipo siempre son subjetivas, pero creo que son unas buenas ideas de partida para mejorar la experiencia.
- Los asistentes me comentaron que posiblemente estaría bien llevar más documentación escrita, eso haría que la pudiesen consultar en cualquier momento y además serviría como apuntes para el futuro.
- En la retrospectiva detecté que hubiese sido interesante realizar algunas preguntas que les hubiese forzado a plantearse nuevas situaciones o problemas, de forma que surgiesen más dudas respecto al uso diario de Scrum.
- Mantener el proceso lo más simple posible y dejarles tomar decisiones hace que se esfuercen mucho y hagan sus propias preguntas. Siempre dentro de unos límites para que no se alejen de Scrum, al fin y al cabo primero tienen que aprender como funciona, antes de cambiar nada.
- Dejar algunas tareas definidas de manera poco específica hizo que al final de un sprint se dieran cuenta que quizás esa no era la solución deseada, eso está muy bien porque es algo que ocurre en la vida real continuamente.
No lo tengo claro, pero quizás vosotros me podais dar una segunda opinión respecto a algunos temas.
- ¿Sería interesante aumentar el tiempo del taller para que los asistentes aprendan a crear historias de usuarios? Yo no tengo clara mi posición respecto a esta cuestión, aunque siempre he creído que las historias de usuario pueden ser un taller bastante largo por si solas.
- El equipo en ningún momento creó tarjetas ni actualizó el scrum board durante la iteración, ¿habría sido interesante alargar el taller y que lo hicieran? Debido al límite temporal del taller decidí que dicha actividad no les habría aportado tanto como el resto, por lo tanto es algo que les expliqué y debatimos pero no se practicó.
- En vez de tener una única retrospectiva al final del taller, ¿sería interesante hacer una retrospectiva al final de cada sprint, teniendo en cuenta el coste temporal para el taller?
Espero que os haya gustado y que aporteis cosas nuevas o intenteis hacer vuestro propio taller, cualquier anotación o experiencia será bien recibida :-)
Comentarios
Que buena pinta tenía el curso. Para la próxima avisa que me apunto :D
El tema de las historias de usuario, creo que se complica bastante en función del tamaño y complejidad del "negocio". Cuando empecé a formarme en metodologías ágiles me parecían algo trivial, pero a medida que tratas de aplicarlo a problemas reales... se complica, y mucho. Un taller/curso específico sería bastante apropiado.
Una de las cosas que más me gusta de Scrum es la "obligación" de realizar las retrospectivas. Creo que fue el cambio más grande que noté con la forma de trabajar que había tenido hasta el momento, donde nadie se paraba a analizar errores y aciertos anteriores, lo que no nos permitía mejorar y encima volvíamos a tropezar en las mismas piedras.
El hecho de hacer una retrospectiva ya abre suficiente los ojos a la mayoría.
Tienes razón, el tema de las historias de usuario parece muy sencillo, pero cuando lo empiezas a utilizar es cuando realmente entiendes su complejidad. Y me gusta mucho tu opinión de las retrospectivas, muy cierto, es una actividad que cambia totalmente la actitud de un equipo, se haga Scrum o no.
Un abrazo.
Un saludo.