El pasado día 7 de junio nos juntamos en las oficinas de Flywire para una nueva reunión del grupo de Agile Levante, organizado por Emma López (@hell03610).
El taller consistía en la realización de dos dinámicas lúdicas, aprendiendo de ellas diferentes tipos de problemas que surgen en entornos de desarrollo.
Comunicación y visión compartida
La primera dinámica se realizaba en parejas. Una persona era el constructor y la otra el gestor (creo, no recuerdo muy bien los nombres). La idea era cambiar en base a los roles que ejecutamos en nuestro día a día para entender el papel de la otra persona.
Emma le dio a cada gestor unas instrucciones para hacer una figura de origami (la conocida ranita) para que se las dictará al constructor. El constructor, apoyado en una mesa, con un folio, y de espaldas al gestor, no podía verlas no podía tampoco hablar con el gestor.
Así mismo el gestor tampoco podía ver lo que iba haciendo el constructor en base a sus indicaciones, con lo cual, imaginaos lo que salió de ahi. Ningún equipo consiguió finalizar algo similar a una ranita 🙁
En la segunda ronda, el gestor podía ver lo que realizaba el constructor e ir guiándole en consonancia a los pasos que daba. En este fase, sólo 2 equipos acabaron las ranitas.
Y en la tercera ronda, tanto el gestor como el constructor, veían las instrucciones. El gestor ayudaba al constructor guiándole y explicándoselas. En este caso todos los equipos acabaron las ranitas y a una mayor velocidad.
De este juego, se extrae la importancia de compartir todos los miembros del equipo la misma visión, y que está quede de alguna manera reflejada de una forma visual, ya que las palabras dependiendo de quien las interprete pueden tener diferentes significados.
Y es como dice Dani Latorre en este post sobre Una de BDD, Specification by Example y Cucumber: «Muchos problemas cuando desarrollamos software surgen de los malentendidos de comunicación entre los diferentes miembros del equipo. »
Estimación, competitividad y la importancia del testeo
En el segundo juego nos dividimos en 2 equipos. Emma nos dio 3 tipos de aviones diferentes a construir en papel, cada uno en folios de un color. Dependiendo de su dificultad cada tipo valía unos puntos u otros.
Probando los resultados d las divertidas dinamicas y juegos #agile en @FlywireEng con @AgileLevante #avionesVoladores pic.twitter.com/fhYD29gxAA
— SaraClip (@saraclip) 7 de junio de 2017
En una reunión inicial, debíamos decirle cada equipo, cuantos aviones de cada tipo íbamos a entregarle en los 4 minutos de tiempo para construir que disponíamos con el requisito imprescindible de que pasasen su test de vuelo.
Ahí, ya cometimos el primer error. Estimamos pensando en que TODOS iban a volar, es decir, el número de aviones que íbamos a construir en los 4 minutos no tenía que ser el mismo que el numero de aviones que iba a pasar el test.
Y lo que es peor, nos pusimos a hacer aviones como locos, sin probar antes que alguno volase (Hola?? TESTEO!!), para en el caso de que no lo consiguiesen, introducir alguna mejora. Emma no nos había especificado que no podíamos cambiar los diseños, simplemente dimos por hecho que no podíamos hacerlo.
La primera ronda fue un desastre. Uno de los equipos aun consiguió acercarse «algo» a la estimación, pero el otro, confiado en que iba a poder construir un número elevado del avión más difícil (que valía más puntos) destinó una elevada cantidad de recursos (3 miembros) en ello y no entrego ni un solo avión de ese tipo.
En la segunda y tercera ronda, con algunas lecciones aprendidas, las estimaciones fueron más correctas, pero aun así se quedaron lejos de la realidad.
Pero lo peor de todo, es que nos centramos exclusivamente en ganar al otro equipo, es decir, la competitividad nos volvió ciegos.
Para ello, ambos equipos, utilizamos la técnica del trabajo en cadena, y en la especialización. Cada uno hacía una parte del avión, pasándosela al siguiente, sin pensar en nada más (Triste, eh?)
Es decir, en vez de probar e investigar otras técnicas nos ceñimos exclusivamente en hacer aquellos aviones que eran más sencillos, para hacer el mayor número posible.
En vez de valorar la calidad, nos centramos exclusivamente en la cantidad.
Como dijo Emma, ese día estaba benévola, y no se ponía a mirar los pliegos de los aviones, su nivel de aceptación, era exclusivamente que volasen más alla del espacio definido. Y nuestra mente sólo podía pensar que a mayor número de aviones construidos, más fácil era que alguno de ellos volase y pasase la prueba.
En resumen, una tarde divertida, en la que nos dimos cuenta como nuestras mentes nos juegan malas pasadas y nos hacen olvidar muchas veces lo importante, como la importancia de realizar pruebas reales y la mejora e innovación en base a los resultados.