Preparades… Listes… Retro! Retrospectivas para principiantes.

"Ahh, la recompensa por un año de trabajo y sacrificio. Retrospecticus!" (Lisa Simpson)

Para leer este post en inglés, haz click aqui.

Recordemos el Manifiesto Ágil: "A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, para luego afinar y ajustar su comportamiento en consecuencia". Todes hemos oído hablar de la ceremonia en la que revisamos lo ocurrido en el último sprint (o al menos una parte) y aprendemos de la experiencia. Como si juntáramos las piezas de un intrincado rompecabezas al final de la iteración, esperando formar al menos el 80% de todo el paisaje (Aunque siempre alguna pieza perdemos, ¿no? Bueno, acá también suele pasar). Es un momento para indagar lecciones aprendidas y métodos de mejora, con el objetivo de revisar, inspeccionar y adaptar constantemente. Con esto en mente, todo va siempre sin problemas y el equipo nunca es reacio a unirse y participar en estas reuniones, dándolo todo, compartiendo experiencias y preocupaciones abiertamente y sin ninguna vergüenza.
Ok, casi.
Hay muchos fallos o complicaciones que pueden surgir al enfrentarse a este tipo de reuniones en que un equipo debe aclarar sus opiniones y experiencias, sobre sí misme o sobre les demás. Aunque son relativamente cortas, puede haber problemas de tiempo cuando no se prepara todo de antemano o se pierden minutos alistando la sala o buscando miembros del equipo alrededor de la oficina. Puede haber contratiempos de conexión o algún otro de los habituales problemas que surgen cuando se trata de equipos distribuidos y retros remotas. ¡A no desesperar! Donde hay voluntad, todo se puede. Analizemos algunos de los problemas que podríamos estar enfrentando a ver si, con suerte, los barremos del tablero.

¿Miedo escénico?

Recién empezaba en un proyecto cuando tuve mi primera retrospectiva. Había participado en ellas en la calidez del apprenticeship, tratando con gente con la que almorzaba todos los días, discutiendo ideas sobre mi trabajo, temas que salían a la superficie en este pequeño proyecto interno en el que estábamos. Sin embargo, cada vez que hablaba de estas reuniones con otres compañeres de trabajo en la oficina, llamándolas "retrospectivas", fruncían un poco el ceño... "Bueno, las llamamos retros pero en realidad no lo son". Poco sabía yo que lo que estaba haciendo era sólo un indicio de lo que iba a venir en un proyecto “real”.

La mañana anterior a mi primera retrospectiva la pasé pensando cosas para decir, y estaba seguro de que tenía preparados unos buenos 2 o 3 minutos de discurso. Pero al llegar el momento me encontré con cuatro personas que llevaban años en el proyecto, hablando de experiencias que nunca había tenido, o problemas a los que nunca me había enfrentado, y me bloqueé, se me atascó el cerebro y, al parecer, se me hinchó la lengua. La reunión llegó y se fue y no pude decir nada. Ni siquiera pude presentarme adecuadamente cuando se me pidió. Todos mis miedos cobraron vida, mi autoestima cayó en picada, y creo que incluso sentí calambres en el brazo izquierdo. Bueno, puede que no haya sido para tanto, pero entonces, ¿qué pasó? Y lo más importante, ¿qué hacer para que no volviera a pasar?

¡Notepad al rescate!

En primer lugar, en vez de pensar qué decir unas horas antes, es mejor escribir las cosas a lo largo del sprint. ¿Notaste que la velocidad sube cuando hacés pairing? Escribilo. ¿Tenés mucho tiempo muerto por falta de tickets? Escribilo. ¿Une miembre del equipo regresó después de unas largas vacaciones? Anotalo. ¿Encontraste un montón de código duplicado mientras trabajabas en una parte del proyecto olvidada por Dios? Notita. ¿La luz de la heladera se quemó? Bueno, mmm, anotalo si querés, pero no da para retro. ¡Creeme que esta técnica funciona de verdad! En tu trabajo diario, tené a mano un bloc de notas (prefiero el papel real a los archivos) y siempre que consideres algo digno de mención para el equipo, escribilo. Incluso si es un asunto menor. Hacelo en ese mismo momento. Te sorprenderá cómo las ideas breves o las preocupaciones aisladas cobran vida cuando las ponés en contexto, y también vas a tener una sensación de repetición, como si ya las hubieras discutido antes.

¡No lo merezco! ¡No lo merezco!

Por supuesto que te sentirás insegure. Elles, al menos en tu mente, son les maestres del codigoverso, criaturas de infinita sabiduría y completa conciencia del dominio. Ni siquiera nunca jamás usan comillas dobles en lugar de simples. Su código y su técnica son impecables. ¿Cómo podría une simple aprendiz como vos estar a la altura de sus expectativas o al mismo nivel?

Bueno, no te preocupes, no es así para nada.

Descubrí que mis temores no tenían sentido. De hecho, en las bóvedas de la historia de la Sabiduría Ágil hay un tesoro que acortará tu camino hacia el coraje:

"Independientemente de lo que descubramos, entendemos y creemos verdaderamente que cada uno hizo el mejor trabajo que pudo, dado lo que se sabía en ese momento, sus habilidades y destrezas, los recursos disponibles y la situación en cuestión"

Bastante copado, ¿no? Es la Prime Directive (Sí, en mayúsculas, así de significativa es) introducida por Norman Kerth en el año 2001, cuando el manifiesto ágil era ASÍ de chiquitito. Tiene tal importancia que debería ser leída antes de cada retrospectiva. En latín, preferiblemente.

Aunque se explica por sí misma y parece hasta casi obvia, es esencial para confirmar explícitamente el papel que desempeñamos en el equipo y lo que podemos aportar a la mesa. Nos iguala, nos tranquiliza. Descubrí que algunos de mis compañeres de equipo cometían los mismos errores que yo y, a veces, yo mismo había hecho progresos en áreas que habían estado en la heladera durante años. Siempre tengan en cuenta la Prime Directive y sepan que les adultes cometen errores, incluso les más entrenades e inteligentes que se puedan imaginar. La frase de Ken Blanchard: "Ninguno de nosotros es tan inteligente como todos nosotros" es clave. No importa tu nivel de experiencia o antigüedad, tu equipo sabe y vos misme debés estar convencide de que sos tan importante como todes les demás. De hecho, el punto de vista de une recién llegade suele estar menos contaminado por las ideas preconcebidas y la subjetividad. Y es bastante bien recibido por ello. Usá tu ingenuidad en tu beneficio. Valdrá la pena.

Espiquin inglish?

¿Qué? ¿En inglés? ¿Qué lo qué? No sólo no conocía a ninguna de esas personas de antemano, sino que encima tenía que hablar en inglés. Admito que me defiendo bastante bien en ese idioma, pero nunca lo había hablado en un ambiente laboral, nunca con les representantes de los clientes, y nunca jamás recién empezando en un proyecto.

Cuando la reunión comenzó no podía entender casi nada de lo que decían, y no me salían ni las frases simples, y mucho menos bloques complejos de discurso. Luego entendí que mis nervios, claramente, estaban injustificados.

Hay un par de cuestiones a tener en cuenta cuando se trata de una reunión en un idioma extranjero. En primer lugar, tranquilícense. Acepten que no son ingleses (O americanos), no fuercen el acento. Además, la mayoría de les desarrolladores están acostumbrades a trabajar en equipos distribuidos alrededor del mundo. Recuerden, una vez más, la Prime Directive. Es decir, saben que estás haciendo lo mejor que podés, y van a poner el mismo esfuerzo en entenderte que el que ponés en hablar su idioma. Al principio ,no intentés frases complicadas. Mantenelo simple hasta que estés lo suficientemente segure. Recordá que la mayoría de tu trabajo se hace en inglés, así que cuando quieras explicar los problemas encontrados desde la última iteración, o los sentimientos del grupo, usa las herramientas que conoces, la jerga que escribís todos los días. Todo el mundo sabe de lo que estás hablando. Cuando alguien habla, mirá la forma en que lo hace, sus gestos, obtené el significado central. A todes se nos escapan algunas palabras, es casi imposible entenderlo todo, pero si entendés los temas clave, ya está.

¡Tan lejos, tan cerca!

Las retrospectivas remotas presentan una complejidad extra. Sin embargo, son la piedra angular de cualquier equipo distribuido funcional. ¡Spoiler alert! Vas a trabajar con gente de todo el mundo. Así que el viejo truco del post-it en la pizarra no va a servir. O al menos no tan bien como cuando tenés reuniones (papas fritas y cerveza incluidas) con tus compañeres de oficina. Familiarizate con las herramientas online. Vas a tener que dominar Google meet, Trello y la mar en coche.

El proceso para organizar una retrospectiva remota es similar al de las presenciales, pero estar en la misma habitación es más poderoso por la comunicación de alto ancho de banda que obtenés. Podés ver si alguien está cansade o frustrade, o feliz y entusiasmade a simple vista.

Algunos consejos para facilitar la experiencia: Evitá ringtones y celulares. Evitá teclear a lo loco. Si querés que te tomen como une miembre más del equipo, y querés que se tenga en cuenta toda tu experiencia, entonces tenés que comprometer tu atención total. El resto puede esperar hasta más tarde. ¿No es estresante y frustrante cuando hablás con el corazón abierto y tu interlocutore está mirando el teléfono? ¡Dejá el teléfono en paz! No posteés en facebook ni en twitter ni stackoverflowées cuando alguien está hablando.

En retrospectiva...

Una vez que te hayas familiarizado con las retrospectivas, te vas a sentir más segure dentro de tu equipo, y ya sea en tu propia oficina o de forma remota, vas a sacar el máximo provecho de ellas. No olvidés algunos de los puntos clave antedichos. Aplicalos si te sentís cómode, o incluso seguí buscando consejos y sugerencias online.

Los fundamentos de las retrospectivas pueden explicarse elaborando algunas preguntas clave. Preguntamos "¿Qué salió bien?" para explorar y celebrar las buenas prácticas que el equipo lleva adelante. Esto da energía al equipo, y lo empuja a experimentar más. Cuando preguntamos "¿Qué no salió tan bien?" exploramos el trasfondo de los problemas que surgieron, desarrollando una comprensión compartida de los temas en cuestión. Preguntamos "¿Qué es lo que todavía nos preoupa?" para ayudar a les miembres del equipo a tener la oportunidad de preguntar sobre los problemas que podrían haber quedado atrapados en la velocidad de la iteración.

A fin de cuentas, espero que este post ayude a les principiantes a romper el hielo en la experiencia retrospectiva y permita que tu equipo tome el envión que necesita para enfrentar los sprints venideros.