Las retrospectivas son una parte fundamental del proceso Scrum y juegan un papel muy importante en facilitar la inspección y adaptación del proceso en el desarrollo iterativo e incremental.
El objetivo es tener la oportunidad de ser transparentes acerca de los temas que preocupan al equipo Scrum. Inspeccionar y adaptar posibles soluciones a los mismos.
Scrum no prescribe cómo deben ser las retrospectivas. Prescribe que debe existir una evento que de la oportunidad de mejorar nuestro control empírico de procesos.
A continuación siete de los errores más comunes y menos conocidos por los que las retrospectivas son un fracaso.
Demasiada facilitación
Gracias a Agile Retrospectives (Diana Larssen y Esther Derby), herramientas como el Rear-O-Mat de Corinna Baldauf y sitios como Tasty Cupcakes de Michael Sahota, hay una increíble variedad de actividades posibles para realizar en retrospectivas.
Sin embargo en muchas ocasiones se pierde el objetivo de las mismas. Se convierten en un espacio para jugar y divertirse y evitar precisamente hablar de los temas que más preocupan al equipo.
Puede ocurrir cuando abusamos del modelo de los cinco pasos.
Las retrospectivas más potentes que he facilitado son aquellas donde los participantes entienden perfectamente cual es el objetivo y avanzan hacia él. Las dinámicas son medios y no fines para conseguirlo.
El Scrum Master no participa
La abundancia de herramientas e información ha hecho que muchos equipos se alejen del verdadero motivo de las retrospectivas para centrarse en las dinámicasSorprendentemente encuentro muchos Scrum Masters que no participan en las retrospectivas, a pesar de que se quejan de que Scrum no funciona en su organización.
Es una paradoja interesante.
Se ha aceptado que el Scrum Master tiene que actuar de facilitador del resto del equipo Scrum en la retrospectiva y eso lo coloca en una posición de dominación de la situación que exime de responsabilidad al resto de los miembros del equipo. El Scrum Master debe de participar en la retrospectiva como uno más, y no quedarse en la seguridad que le da el ser el que sabe de Scrum.
La presencia de externos en la retrospectiva
En algunas organizaciones, las retrospectivas han pasado de ser la reunión que no interesaba a nadie a ser el espacio para que cualquiera acuda a comentar problemas que consideran oportunos o hablar de sus propias preocupaciones.
La retrospectiva es un espacio exclusivo para el equipo Scrum, y los participantes externos no son bienvenidos.
Es muy complicado crear un entorno de seguridad para que los participantes hablen cuando saben que pueden ser juzgados por alguien que no entiende las dinámicas de un equipo Scrum.
Nadie habla de los verdaderos problemas
De nada sirven las dinámicas divertidas si los valores de Scrum no están presentes.
Hace poco describía una situacion en la que Scrum parecía un teatro en lugar de algo productivo.
Scrum requiere de dos valores fundamentales: Confianza y Coraje.
Aún así, muchos equipos no tienen ninguno de los dos y en la retrospectiva solamente tienden a hablar de cosas simples y no tratar los verdaderos problemas.
La labor del Scrum Master es gestionar Scrum y promulgar los valores de Scrum; si el resto del equipo Scrum no tiene coraje para hablar de los problemas que les afectan, el Scrum Master tiene la responsabilidad de hacerlo.
De nada sirven las dinámicas divertidas si los valores de Scrum no están presentes.
El momento de los sentimientos
¿Quieres que tus compañeros de equipo sean felices? Entonces ayudarles a que puedan hacer su trabajo eliminando impedimentos organizacionales.
Algunos Scrum Masters y equipos Scrum ven las retrospectivas como el momento terapia, donde se habla de sentimientos y relaciones personales.
Esto está bien, siempre y cuando: a. Sean problemas reales de los equipos y b. Sean los aspectos más importantes a tratar, decididos por el equipo.
La Psicología es genial cuando los verdaderos problemas son de relaciones humanas y para un martillo todos son clavos.
Nuestra labor es cómo Scrum Masters, no como Psicólogos.
De nada sirve un equipo Scrum que se quiere si la calidad del producto que desarrollan es pésima.
Tratar a los compañeros como si fueran estúpidos
Es común ver a developers que se sienten tratados como si no tuvieran ni idea de relaciones, o de que significa hacer una retrospectiva, o cómo si no supieran Scrum.
Si tratamos al equipo Scrum como niños, se comportaran como niños.
Si la única manera que tenemos de hablar de los problemas es a través de juegos y metáforas, ¿Cómo esperamos alcanzar soluciones adultas?
El momento de gloria del Scrum Master
Por último, la retrospectiva debe ser el momento de todo el equipo Scrum, no los 60 minutos de gloria del Scrum Master.
He visto Scrum Masters enfadados con el resto del equipo porque no participaban en sus increíbles dinámicas o no hablaban de los problemas que el Scrum Master quería que hablaran.
Una retrospectiva es una actividad orgánica, decidida por todo el equipo Scrum, en la que se tratan los temas que ellos consideran oportunos, y no el momento para que el Scrum Master despliegue su conocimiento sobre dinámicas de equipo.
Escuchar antes que actuar.
Es importante no perder el foco y objetivo de cada evento