Varios años de experiencia en retrospectivas en diferentes culturas me han dado como resultado algunas técnicas interesantes para mejorar el rendimiento de tu equipo y entender más sobre el funcionamiento humano. En ésta entrada te lo mostraré desde el punto de vista de un Scrum Master, pero podría ser aplicada y brindada al grupo por cualquier integrante.
La retrospectiva Robot
Especialmente para los recién entrados en la dinámica Agile (aunque también lo he visto en grupos que llevan ya cierto tiempo), las retrospectivas se convierten en reuniones muy automáticas («robóticas») y siempre al final del ciclo; esto es:
1. Se plantea lo que se hizo mal
2. Se indica lo que se podría mejorar
3. Se comenta lo que se hizo bien
4. Se ponen ciertas medidas o ajustes y finalmente se da por acabada la reunión.
El mayor problema es que ésta modalidad en el largo plazo puede ocasionar mas inconvenientes que soluciones. El primer punto a entender es porqué se llevan adelante las reuniones en Agile/Scrum y cual es el fin de realizar ciertas preguntas. El hecho de que las preguntas estén allí no es primordialmente para para conocer información acerca del resultado de los procesos, sino que principalmente para modelar un comportamiento, esto es, poner a los individuos dentro de cierto patrón de pensamiento y acción.
«Las preguntas en las reuniones Agile se efectúan para modelar un comportamiento»
Por supuesto que de forma secundaria está el obtener información y hacer algo con ella, como ser remover obstáculos, cambiar un proceso, etc.
La retrospectiva es algo entonces que no debe ser tomada a la ligera ya que es el único punto donde el grupo puede radicalmente cambiar su dirección mediante la toma de decisiones, adoptar medidas y aprender para el mediano y largo plazo. Podrías pensar que la reunión Standup diaria tiene un fin similar, no obstante, ésta última ataca obstaculos relacionados principalmente con las historias de usuarios y no del grupo en si.
La mayor carencia con la modalidad de reunión «robot» es que existen infinidad de problemas que no pueden ser sacados a la luz a no ser que se empleen técnicas que apunten estos inconvenientes de forma directa pero despersonalizada. Acuérdate que el trabajo del último ciclo es siempre:
1. Reciente
2. Involucra a todos en forma grupal y principalmente personal
3. Las personas se sienten orgullosas de lo que desarrollaron
Es así que varios problemas pueden esconderse bajo formas de trabajo no adecuadas que muten ciclo a ciclo con el fin de poder «ocultarse» de la vista de un simple mortal.
El modelo de Muzafer Sherif problema 1
Imagínate que tu eres nuevo en un grupo Scrum de 5 personas y que a uno de los integrantes más aceptados no le gusta o quiere escribir pruebas unitarias. El resultados menos deseable es que otro integrante o integrantes decidan cubrir la tarea mediante la escritura adicional de los mismos ciclo a ciclo. Esto que puede parecer trivial, hace que el problema de fondo enmascare a una problemática que afectará el rendimiento del equipo en todos sus ciclos Sprint futuros y que raramente podrá ser detectada en una retrospectiva «robot». Esto es así ya que los miembros encontraron una «solución» paleativa de corto plazo, la que será luego extendida indefinidamente.
Muzafer Sherif
Este proceso que fue explicado por Muzafer Sherif, famoso sociólogo nacido a comienzos del siglo pasado. Éste indica que el grupo ejerce influencia normativa, ya que mantener opiniones diferentes puede afectar a la integridad del equipo y así ocasionar rechazo. De esta forma, si alguno de los actores que cuentan con más influencia deciden moverse en otra dirección, los demás podrían aceptar el problema y buscar una solución «temporal» para no generar un rechazo. Así se estará alejando paulatinamente de la optimización de las tareas, cosa fundamental en Agile.
El modelo de Muzafer Sherif problema 2
Ahora imagínate que no eres nuevo y tienes algo más de soltura con el grupo de Scrum y decides mencionar el problema. En todo caso, se podría aplicar la segunda regla que especifica que constantemente corroboramos la información con los demás integrantes del grupo, por lo que si opinamos algo diferente a lo que el conjunto opina, adoptaremos su punto de vista para evitar estar equivocados. Esto obviamente haría que finalmente -y aunque pienses que las cosas no están bien- aceptes la mayoría por miedo a equivocarte.
El resultado final es que el proceso se verá altamente comprometido, eso es, se generará un montón de tareas pequeñas que consumirán tiempo y no redituarán en valor agregado al cliente ni equipo.
La solución para el problema de Sherif 1 y 2
Ante la duda recomiendo emplear siempre una de las reglas fundamentales de las metodologías LEAN la que indica que se debe optimizar siempre el tiempo de la totalidad de los procesos desde el nacimiento del requerimiento hasta que el cliente lo tiene en sus manos (en este caso en software funcionando) y retirar todos los bloqueos que obstaculizan al mismo.
Por ejemplo, una pregunta acertada en la retrospectiva sería «¿Qué procesos nos inhabilitan a reducir los tiempos desde concepto a entrega?» y se podría mostrar un esquema de los sitintos procesos y tiempos.
Mala aplicación de la teoría de encolamiento y restricciones
La teoría de encolamiento y restricciones reconoce que la producción de un sistema consiste en múltiples pasos, donde el resultado de cada uno de esos pasos depende del resultado de pasos previos y plantea soluciones para mejorar los pasos menos productivos. Imagínate que en cada ciclo de trabajo los desarrolladores se quejan porque el o los «testers» toman mucho tiempo en realizar las pruebas. Un vistazo inicial al proceso podría verse como el siguiente:
Asumiendo que el cuello de botella está en los procesos de prueba, el grupo podría elegir en la retrospectiva llevar adelante alguna de las siguientes acciones para el próximo ciclo:
1. Adicionar mas «testers»
2. Mover ciertos desarrolladores a la parte de prueba para ayudar a los «testers»
3. Evaluar otro software de pruebas que sea más rápido
No obstante, esto daría en la mayoría de los casos una caída en la productividad debida a la curva de aprendizaje o menor cantidad de recursos disponibles en un área por el pasaje a otra. En realidad, un análisis por menorizado nos muestra que el problema no está en el proceso de prueba sino que el cuello de botella se encuentra en el desarrollo, el que no cuenta con un micro-ciclo consistente y finaliza todas sus historias de usuario y pasaje a los testers al mismo tiempo, produciendo así un bloqueo del proceso.
Esto puede ser el resultado de un tamaño excesivo de historias de usuario, otros procesos que consumen tiempo de desarrollo pero no agreguen valor, o incluso un mal funcionamiento del sector de programación ya sea por requisitos definidos por el grupo o políticas de la empresa.
Es así que nuevamente hay que analizar los micro-procesos de forma unitaria y ligarlos a su totalidad para ver porqué un área del equipo se ve desbordada de trabajo. A su vez, lo que yo llamo presbicia de proceso (incapacidad de ver algo si lo tienes cerca) y el cuidado que ponen muchas personas en no herir a otras, hace que los problemas no puedan salir a la luz mediante el desarrollo de una retrospectiva típica.
Técnica abstracta: la música
Una de las cosas que hay que tener en mente es siempre deslindar el sentimiento personal sobre las tareas realizadas y asumirlas a modo de grupo. Si se falló ha sido el equipo y nunca un individuo en particular (esto asume sinceridad y no solamente que se diga pero no se asuma). De haber un conflicto siempre se deben poner reglas claras sobre comportamiento y respeto mutuo y exhibirlas al comienzo de cada retrospectiva.
No obstante, el elevar los problemas a un plano mas abstracto puede ayudar; yo he experimentado con la técnica que te detallaré y obtenido un resultado excelente.
El funcionamiento
1. Se reparte a cada integrante una tarjeta y un lápiz
2. Se solicita a los participantes escribir en un trozo de papel hasta 2 temas musicales que representen al último ciclo de trabajo
3. Se pide de a un intrgrante a la vez que explique el porqué del tema musical.
4. Opcionalmente se puede solicitar a la persona que cante un trozo, lo que hará la reunión más divertida.
Ej.
Pedro: «Elegí «Welcome to the jungle de XXX» porque ha sido como una jungla para mi, cuidándome la espalda todo el tiempo, corriendo y viendo si sobrevivo; finalmente elegí la 5ta sinfonía de Beethoven porque el final fué muy armonioso »
Es normal que los primeros participantes comiencen tímidamente su exposición y poco a poco se animen a más, por lo que es siempre recomendable elegir a las personas más extrovertidas al principio. A su vez, se busca inicialmente respuestas metafóricas como «corriendo y viendo si sobrevivo». Obviamente no se trata de una situación real, ya que de lo contrario el integrante sería integrante de un grupo de choque de la marina y no de desarrollo de software.
Regla 1:
Cuando se hace la exposición no debes interrumpir a la persona hasta que termine pero si tomar nota. Una vez finalizada debes comenzar a preguntar en forma figurada pero que lleve a resultados directos, por ejemplo «¿Qué quieres decir por correr por tu vida?» y mover las respuestas poco a poco hacia términos reales.
Más abstracto Más directo
<————————————————————->
1era pregunta ->
………2nda pregunta ->
……………………………………etc ->
………………………………………………etc ->
Regla 2:
Una vez que se tiene algo como «El Jefe de producto me presionó para terminar con la historia», no emites opinión personal, lo anotas en una tarjeta y lo pones en la pizarra.
Regla 3:
Una vez finalizada la vuelta agrupas o remueves aquellos redundantes y le pides al equipo que los pongan en orden de prioridad de acuerdo a lo que consideren haga mas daño a menos.
Regla 4:
Finalmente seleccionas 4, examinas posibles soluciones y medidas a tomar en el próximo ciclo y las anotas y las dejas disponibles para que el grupo las vea día a día o pones algunos centinelas que verifiquen que todo va bien.
Técnica abstracta direccional: los personajes
Uno de los inconvenientes que puedes encontrar es que pese a que el problema esté allí y sea visible para ti, no sea obvio para el grupo y no pueda ser obtenido mediante la técnica anterior. Es así que esta segunda opción emplea algunas prácticas «inocentes» y más acertivas que comienzan poco a poco a involucrar a la retrospectiva los problemas existentes.
Preparación
Antes de la reunión deberás buscar fotos de dibujos animados e imprimirlos (tantos de cada uno como personas en el equipo; si hay 5 personas y tienes 10, entonces imprimirás 50). Si el ciclo ha sido caótico, puedes poner más dibujos animados de guerra, si han habido conflictos de poder podría ser la imágen de un dibujito que a tu criterio lo represente (podría ser por ejemplo Pinkie cerebro), etc.; todo esto mezclado con otros más generales.
El funcionamiento
1. Se cortan pequeño y se ponen todos los impresos en la mesa y se da 1 minuto a los integrantes para seleccionar hasta 3 personajes que representaron el último ciclo.
2. Pedir a un integrante a la vez que explique el porqué de su selección y aplicar la técnica de pregunta global a específica indicada anteriormente.
3. Anota en una tarjeta la respuesta final y ponerla en la pizara.
El proceso posterior es similar, se analizan los problemas, se priorizan y se busca un plan a llevar adelante.
La principal diferencia con la técnica de la música es que aquí se pueden elegir personajes que por sus características pre-dispongan/dirijan a los miembros del equipo a «atacar» a ciertos problemas.
Técnica de acción-reacción
Éste método se me dió como resultado en uno de los equipos bastante conflictivos que tenía en una de las empresas Londinenses y es muy efectivo por su naturaleza, pero requiere en general que los miembros lleven trabajando junto por algun tiempo.
Preparación
La idea es que durante el ciclo se anoten en tarjetas los problemas que van surgiendo, por ejemplo: «Cierto miembro da órdenes a todos los integrantes con los que programa.» y se guarden. Luego antes de retrospctiva se deben transformar estas a nivel general y en forma de pregunta, por ejemplo:
«Jorge da órdenes a todos los integrantes con los que programa.» –> «¿El trabajo en pareja funciona con igualdad de roles o jerárquicamente?»
El funcionamiento
Durante la retrospectiva se deben poner todas las tarjetas en una pizarra dadas vuelta (para que lo sintegrantes no las puedan leer), y se emplea alguna de las técnicas anteriores o las 3 preguntas de la retrospectiva «robot». Finalizada con la parte de averiguación y cuando están ya todos los problemas planteados por el equipo y visibles en la pizarra, se dan vuelta los previamente cubiertos y se discuten para ver si hay algo que se había perdido. En general lo que suele pasar es que el equipo no «descubre» ciertos problemas que se encuentran ocultos hasta que se efectúan las preguntas de las tarjetas pre-escritas.
Luego nuevamente se priorizan los problemas, se indican pasos a seguir y se termina con la reunión.
Esta última técnica es de mucha utilidad cuando el equipo no es capaz de visualizar problemas, se haya olvidado por el estrés del ciclo, o encubierto con alguna accion paleativa.
Finalmente, puedes realizar retrospectivas en cualquier punto, no tiene por que ser al final del ciclo; si hay un problema entonces ella puede ser una solución. Con equipos nuevos es siempre recomendable hacer la retrospectiva parado (removiendo las sillas, mesas y dejando solamente la pizarra) ya que de lo contrario, se tenderá a bifurcar en las conversaciones).
Recuerda… el éxito para una buena retrospectiva es siempre su preparación y no te olvides que los procesos están basados en personas, las que actúan siguiendo un protocolo o interacción que puede ser cambiado siempre y cuando las acciones no sean abruptas y el individuo vea el valor positivo del cambio.
Si quieres recibir mis novedades y artículos haz clic en la pestaña SEGUIR de abajo a la derecha; también te podría interesar alguno de mis otros artículos…
10 reglas de oro para medir un proyecto Agile
Descubriendo los problemas de equipos Agile
Implementar Ágil en paises hispanoparlantes vs. anglosajones
Resultados de 7ma. encuesta anual del estado de Ágil
6 problemas típicos en retrospectivas Ágil
¿Gastar en tecnología o metodologías de gestión de proyecto?
¿Cuándo utilizo Ágil? La respuesta que estabas esperando…
¿Qué hacemos con los recursos humanos en Ágil?
Agilidad y la verdad contundente sobre programación en parejas
Resistencia institucional y cambio hacia Agile (Parte 1)
Resistencia institucional y cambio hacia Agile (Parte 2)
Lo que no se dice de Ágil
Las 15 preguntas antes de implementar Ágil/Scrum en la empresa
