Retrospectivas ágiles y terapias de grupo

Scrum

He oído alguna vez el comentario de que la retrospectiva de un equipo de Scrum es “como una terapia de grupo”. Entiendo el fondo detrás de esto y sé que se dice con buena intención pero, seamos claros, no estoy de acuerdo.

Intención y malentendidos

Está claro que cuando se dice esto, está la intención de querer transmitir que así es como un equipo Scrum resuelve sus problemas, pero la forma en que lo decimos importa. Es una percepción floja, fofa, de lo que se hace en una buena retrospectiva.

Creo que este enfoque da la sensación, y lo digo porque lo he vivido, de que a las retros se va darse abrazos o a contarse las penas.

Otra conclusión que he notado que se extrae en ocasiones de este planteamiento es que el equipo Scrum hace esto para tener un espacio donde simplemente bajar el ritmo durante un rato, desahogarse y salir de allí sintiéndose mejor.

Por no hablar de que fomenta la idea de que durante el Sprint los problemas no se tratan y todo tiene que esperar para explotar en la retro.

No es así y vamos a ver porqué.

Teoría y malentendidos

No voy a copiar aquí todo lo que dice la Guía de Scrum sobre el evento de la Sprint Retrospective pero sí un par de perlas para sentar las bases y dejar las cosas claras.

En el primer párrafo de este apartado de la Guía ya queda bastante claro.

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint

No se define la retro como un espacio donde contarse las penas o donde el Scrum Master tiene que conseguir que todo el mundo se sienta como si todo en el equipo fuese una maravilla. No señores. La retrospectiva se hace para obtener medidas de mejora sobre los propios procesos del equipo y además para implementarlos ya.

Sí que se habla de que el Scrum Master se asegura de que la retrospectiva sea positiva y productiva. ¿Por qué? Porque tampoco es un espacio para echarse pestes ni culpas, lo cual no es lo mismo que no decir las verdades. Sólo evidenciando los problemas y afrontándolos desde el respeto y la sinceridad total se puede llegar a soluciones reales y no limitarse a rascar la superficie.

Se revisa todo lo que tiene que ver con procesos, personas, relaciones (que son hacia adentro y hacia afuera del equipo Scrum) y herramientas. ¿Por qué? Porque todo esto influye en la productividad del equipo, en su capacidad para entregar valor de manera continua y en la calidad del trabajo final que se lleva a cabo.

Y la otra cosa que tampoco dice la Guía de Scrum, sino más bien lo contrario, es que los problemas tengan que esperar a la retrospectiva

Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

Un equipo Scrum inspecciona y adapta continuamente, así debe ser. Lo que la retrospectiva proporciona es un espacio y un tiempo de manera formal reservado para eso, no el único espacio ni momento en el que se puede hacer. Es un matiz, pero es fundamental entenderlo.

¿De dónde vienen los errores?

Saber de dónde vienen estas malas interpretaciones es complicado y dependerá del caso. Es una cuestión de percepción de cada uno.

Una posibilidad muy evidente es no haber leído la Guía de Scrum. El documento PDF en inglés son a día de hoy, con portada e índice incluidos, diecinueve páginas. Si trabajas dentro de un equipo Scrum … excusa eliminada.

Que el Scrum Master no lo esté explicando fuera de los propios equipos. Esto es una posibilidad. Si los equipos Scrum (ojo, no equipos de desarrollo sino Scrum) funcionan como una caja negra eso hay que mejorarlo. En nuestro caso tenemos una formación de Scrum que está abierta a toda la empresa, que yo doy cada mes, y de la que me enorgullece decir que unas cincuenta personas ajenas a los equipos han asistido ya. Y aún así la sigo cambiando porque creo que siempre es mejorable.

Cabe la posibilidad, simplemente de que la persona que tiene esa percepción sólo haya leído un post como este y con eso ya se haya formado una opinión. De nuevo vuelvo a la figura del Scrum Master. Si en tu organización hay uno o más de uno, acude a él a que te lo explique. Si es un buen Scrum Master te lo va a explicar encantado porque le apasionará saber que quieres entenderlo y además sabe, porque ha leído muchas veces la Guía de Scrum, que conseguir que toda la organización entienda Scrum es parte fundamental de su trabajo.

Un equipo que no se esfuerza por mejorar. Esto puede pasar. Scrum es muy bueno pero no mágico. Ni Scrum ni nada va a conseguir un cambio en las personas sin implicación de las mismas. Lo que va a proporcionar son las condiciones idóneas para que ocurra, pero nadie puede ayudar a quien no quiere ayuda. Y el caso es que un equipo que no hace el esfuerzo de mejorar y cuyas retrospectivas sean por ello flojas, va a transmitir esa sensación al exterior. El problema no sería, en este caso, la mecánica sino un falta de compromiso. ¿Qué soluciona Scrum aquí? Poner claramente el problema encima de la mesa.

Soluciones a los malentendidos

Para mí la mejor es una y es sencilla. Como con cualquier cosa que tenga que ver con cosas que no entiendes o no te cuadran sobre los procesos de Scrum, ve y habla con un buen Scrum Master. Te dará una explicación y hasta es posible que se ofrezca a facilitar una para tu equipo y así podéis descubrir de primera mano cómo es la mecánica.

Pero ojo, generar el clima adecuado para que una retrospectiva no se hace en una sesión, la confianza y el respeto de un equipo se ganan y se generan. Cuando la gente se implica y ve las mejoras … se implica más.