Si eres nuevo en el mundo de Agile habrás visto que al final de cada ciclo (Sprint) se realiza una reunión donde básicamente se analiza lo que se ha hecho bien, las cosas que no ha salido como se esperaba y que se puede todavía mejorar. En principio esto puede parecer una reunión fácil de llevar adelante, pero debo decirte que en mis años enseñando Scrum, he visto como fallar en estas ha desmoronado la moral y la productividad de los mejores equipos de trabajo, aquellos más motivados y que parecián indestructibles.
En las reuniones de día a día (Stand Ups) se detectan inconvenientes, los cuales se corrigen sobre la marcha, pero es en la reunión de retrospectiva donde se marca el rumbo y se solucionan los problemas de fondo.
Esto es así ya que al final del ciclo siempre se tiene una visión más clara debido a que:
1. Se pueden enumerar parte de los problemas
Se han finalizado con parte o todas las historias de usuario y han sido aceptadas por el dueño del producto, lo que nos permite poner un punto final. Esto hace que sea mas fácil enumerar los problemas habidos en las distintas etapas.
2. Fin de la miopía del ciclo
Mientras se está en el ciclo se tiene lo que llamo la «miopía de ciclo», en el cual no podemos ver más alla del trabajo que tenemos pendiente por estár zambullidos en los problemas del día a día e historias restantes.
Es así que la retrospectiva es el único mecanismo que permite corregir el rumbo (o inspeccionar y adaptar) y asegurar que se crezca como equipo, a nivel personal y de empresa. No debemos considerar a la reunión como un simple espacio para analizar lo que se hizo mal, ya que de ser así, se estará eligiendo un camino simplista que reducirá la efectividad y potencial de la retrospectiva y hará que los miembros del equipo la vean como algo factible de omitir al final del ciclo.
Esto son algunas de las cosas que deberían darse como resultado de la retrospectiva:
1. Analizar y aprender nuevas formas de interacción con las personas del equipo y/o externas al mismo así como analizar su funcionamiento.
2. Inducir nuevas reglas internas de trabajo y/o modificar las actuales.
3. Vislumbrar soluciones a problemas existentes, tanto sean tecnológicos como de poder (comando y control).
4. Analizar lo que se hizo exitosamente y asegurarse de que se mantendrá ésto en el futuro.
5. Dejar sentado restricciones/formas de trabajo claras para que sean comunicadas a actores externos del grupo.
6. Seleccionar aquellos problemas más destacados, priorizarlos y buscar una solución.
La retrospectiva es un elemento importante que, de ser llevada correctamente, aumenta la confianza y seguridad de las personas del equipo, haciendo que ellas trabajen en confort y puedan aumentar su rendimiento y productividad.
Problema 1: No hay tiempo para la reunión de retrospectivas
Éste es uno de mis puntos favoritos y que he visto más frecuentemente. Si bien a simple vista parece que las personas no tienen tiempo, una visión más cercana puede denotar problemas estructurales todavía más graves, como por ejemplo:
1. Los miembros del equipo no confían en si mismos u otras personas de la empresa (o temen por su puesto de trabajo), lo que hace que no quieran ser expuestos a la fragilidad de poner a la luz los problemas.
2. Trabajan en varios proyectos al mismo tiempo (multitarea), lo que da como resultado que no puedan centrarse en el equipo o historias de usuario. Esto es un déficit en la forma de trabajo Agile, generando ruido (o lo que se llama Muda en las metodologías Lean), bajando así la productividad final. Se deberá aquí buscar una solución que involucre el compromiso de las personas con el proyecto y los estimados.
3. El Scrum Master no es capaz de llevar adelante la reunión de forma en la cual se extraigan realmente los 6 puntos mencionados anteriormente. Debido a ello los miembros no la ven como algo importangte o interesante. Planificación es siempre el mejor antídoto y el que te recomiendo.
4. Las historias de usuario no son suficientemente pequeñas o los estimados de puntos para ciclo Sprint no han sido calculados correctamente.
Es por ello que la regla de los 5 PORQUÉ y el sentido común (¡que es siempre el menos común de todos los sentidos!) es siempre una buena forma de descubrir la raíz del problema. La técnica es utilizada para explorar la relación causa y efecto oculta a simple vista sobre un problema en particular. El número 5 deriva de una observación empírica sobre el número de iteraciones tipicamente necesarias para llevar al fondo de un asunto. La técnica es tan sencilla como efectiva, debes preguntar varias veces sobre un tema; por ejemplo:
1. Scrum Master: ¿Porqué estás ocupado Juan?
Juan: Porque tengo que terminar varias tareas.
2. ¿Porqué tienes que finalizar con varias tareas?
Juan: Porque estoy trabajando en 2 historias de diferentes proyectos
3. ¿Porqué trabajas en historias de más de un proyecto?
Juan: Mi ex-jefe me asignó una tarea adicional hace unos días que me está consumiendo parte de mi tiempo.
En general basta con menos de 5 preguntas para llegar al problema real. Una vez detectado el mismo, se hace mas sencillo el poder lidiar con éste y buscar una solución
Problema 2: Las tareas se asumen a título personal
Hay que admitirlo.. cada tarea de programación que un desarrollador lleva adelante es como su obra maestra y obviamente se siente orgullosa de ella. Esto hace que si algo salió mal, algunas personas lo tomen a titulo personal, o lo que es peor, señalen o inculpen a aquellos «culpables».
En un equipo Agile todos son responsables de los resultados exitosos así como de aquellos no tanto. No existen culpas sino problemas a resolver.
Si esto pasa, quien sea Scrum Master deberá moderar la conversación, recordar que se trata de un equipo y dejar pautas claras sobre el respeto hacia los individios y su trabajo.
De ser un problema reincidente, mi recomendación es pegar en la pared antes de la retrospectica algunas pautas básicas sobre el funcionamiento de la misma.
Problema 3: Monopolización de la retrospectiva
Una de las personas monopoliza la retrospectiva y no deja interactuar a los demas miembros del equipo. Esto es común cuando se tienen individuos que anteriormente se situaban jerárquicamente sobre otras personas (jefes de proyecto, etc) o personas mas extrovertidas. La tarea aquí del Scrum Master es balancear la reunión; una de las técnicas que funcionan bien es el llamado indicador de interacción. Básicamente dibujas cuadrados en una hoja grande con los nombres de las personas en la sala. Cada vez que una sugiere una idea agregas un punto. Ésto dará una idea visual de quienes interactúan y quienes no y su posterior ajuste.
Problema 4: El dueño del producto utiliza la retrospectiva para dar indicaciones claras de que desea en próximos ciclos
Recuerda, no hay relación entre roles y clasificación de problemas, todos estos deberán ser votados y priorizados por el equipo en forma democrática, sin importar su role. Si el dueño del producto no comprende claramente las reglas, está en el Scrum Master en recordárselas y asegurar que las metodologías Agile sean seguidas al pie de la letra.
Problema 5: Los problemas son obvios pero no se mencionan en la retrospectiva
Todavía acuerdo uno de mis equipos en una empresa de Londres donde un consultor y ex-jefe daba órdenes y levantaba la voz a los miembros del equipo. Los mismos me sugirieron realizar una restrospectiva; mi primer pregunta fué si había algún problema en la interacción del equipo. Para mi sorpresa obtuve un «No» seguido como respuesta que todo estaba funcionando correctamente y era una de los mejores ciclos Sprint de la historia de la compañía. En estos casos tienes dos caminos a seguir:
A. Realizar preguntas abiertas para ver si el problema sale a la luz. De esta forma puedes guiar al equipo lentamente hacia una conclusión, pero ten cuidado, no fuerces la situación. En caso que nada surja pasa al mi punto B.
B. Finalizar la retrospectiva y dejar que el equipo falle en algún punto del ciclo actual o futuro. Esto que puede parecer una recomendación poco coeherente, tiene su fundamento en apoyar a los miembros a que maduren en términos agile.
Aquí puedes ver claramente que existía un problema extremo de falta de confianza y miedo de perder su puesto de trabajo, lo que los inhabilitaba a actuar.
Problema 6: Charlas sinfin y no soluciones
Ésto es muy común en equipos Agile nuevos donde no se comprende el sentido real y funcionamiento de la retrospectiva. De ser éste el caso, te recomiendo las siguientes 3 medidas:
1. Retira las sillas de la habitación; las personas paradas tienden a ser más breves y concisas.
2. Prepara la sala antes de la hora de comienzo, pega en las paredes 3 carteles con los textos: «Lo que hicimos bien», «Lo que fué problemático», «Lo que se puede mejorar».
3. Tan pronto como el equipo entra en la habitación pídeles que escriban en trozos de papel las respuestas a las preguntas anteriores (que pueden ser múltiples) y las peguen en cada columna
4. Finalmente prioriza con ellos los problemas y haz que los mismos sean discutidos.
Finalmente, no te olvides que lo que se habla en una retrospectiva allí se queda. Te comento en breve algunas técnicas para obtener lo mejor de cada retrospectiva.
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
Psicología profunda de las 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 recusos 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)
Las 15 preguntas antes de implementar Ágil/Scrum en la empresa
1 pensamiento sobre “6 problemas típicos en retrospectivas Agile”