Quiero hablar un poco sobre la retrospectiva de Scrum, pero primero les voy a contar una historia sobre la autoevaluación.

Cuando estaba en el quinto año, comencé a tomar lecciones de saxofón (puedes reír, ¡pero todos saben que es el instrumento más genial !). Mi maestro era increíble, un músico increíble que había dejado de tocar en clubes de jazz para enseñar.

Las lecciones que aprendí de él fueron para toda la vida: perseverancia, lidiar con las frustraciones, prestar atención a los detalles. Sin embargo, la mejor lección que me enseñó fue el valor de la autoevaluación.

Un día me pidió que comprara una grabadora K7 (sí, hace mucho tiempo) y la llevara a la siguiente clase. La semana siguiente, me grabó tocando una canción que había estado aprendiendo durante semanas. Tan pronto como terminé, dijo: «Está bien, escuchémoslo».

Estaba desconcertado. Acababa de jugar y sabía dónde me había equivocado. ¿Por qué necesitaba escuchar lo que acababa de tocar?

Sin embargo, aquí estaba el problema: lo que pensé que había tocado no se parecía en nada a lo que realmente había tocado.

La grabación reveló todo tipo de errores. Notas desafinadas, fuera de ritmo, inicios incorrectos. Fue espantoso .

La grabadora pronto se convirtió en mi objeto más despreciado. Sin embargo, su valor era claro, incluso en ese momento: a veces, estás seguro de algo que no es cierto.

La nueva perspectiva que obtiene de la autoevaluación es la razón principal para realizar reuniones retrospectivas en Scrum si desea que su equipo Agile se mantenga actualizado y tenga éxito.

¿Qué es una retrospectiva en Scrum?

Una retrospectiva de Scrum es básicamente la siguiente: al final de cada Sprint, el equipo se reúne para hablar sobre el proceso. ¿Qué funcionó? ¿Qué no funcionó? ¿Cómo eliminar obstáculos en el próximo Sprint?

Antes de reunir a todos en una sala y desahogarse sobre las frustraciones, es importante comprender los roles y los objetivos de una retrospectiva de Scrum.

Uno de los principales pilares de la metodología Agile es la idea de mejora continua en la productividad del equipo.

Cada Sprint debería ser un poco más eficiente que el anterior. La única forma de hacer esto es comprender dónde están las debilidades en el proceso e implementar estrategias para superarlas.

Ésta es la importancia de la retrospectiva de Scrum.

Michael Silvi es consultor senior en Stride , una consultora de desarrollo de software en Nueva York. Ha estado ayudando a los equipos a implementar la metodología Agile y Scrum durante siete años, enfatizando la estructura formal (que detallaremos a continuación) para el éxito en la retrospectiva.

Luego comparte su experiencia sobre la estructura, roles y objetivos de una retrospectiva Sprint efectiva.

¿Por qué todos ignoran las retrospectivas?

En ese momento de las lecciones de saxofón, odiaba la flauta dulce porque me obligaba a escuchar todos los horribles errores que cometía. Las retrospectivas en Scrum tienen el mismo efecto, y enfrentar nuestros errores requiere madurez y confianza en uno mismo.

«Necesitamos estar en un ambiente de confianza», dice Silvi. “La idea es lavar la ropa sucia, así que, sin confianza, muchos equipos terminan evitando las retrospectivas”.

La presión del trabajo también es un factor. Silvi dice que los equipos están bajo mucha presión para entregar todo a tiempo , por lo que existe la creencia de que detenerse a reflexionar obstaculizará el trabajo.

O, quizás, el equipo ha experimentado con la celebración de reuniones retrospectivas en el pasado, pero se perdió un proceso eficiente para mejorar realmente el trabajo, por lo que decidió que no valía la pena.

Sin embargo, esta mentalidad a corto plazo conduce a problemas a largo plazo.

“Si no se detiene a discutir los desafíos, puede terminar ignorando un problema sistémico y perdiendo de vista la causa que ha vinculado la situación”, dice Silvi.

Si no comenta los problemas que ve en el proceso de trabajo del equipo, seguirá repitiendo los mismos errores. El simple hecho de evaluar su trabajo, identificar problemas y llegar a una solución puede tener efectos positivos y profundos.

Silvi cuenta el caso de cuando trabajó con un equipo que esperó seis meses para implementar reuniones retrospectivas regulares en Scrum. Continuaron identificando los mismos problemas en todo Sprint: “No teníamos una asociación lo suficientemente sólida con el equipo de producto. Trabajé sin saber por qué estaba trabajando. Solo recibí órdenes ”, comenta un miembro del equipo.

«Sin conocimiento del producto, estaba creando soluciones inadecuadas, trabajando más de lo necesario y teniendo que volver a trabajar con frecuencia».

Además de perder el tiempo, los problemas repetidos erosionan la moral del equipo. Con reuniones retrospectivas en Scrum, el equipo pudo acercarse al equipo de producto, conocer los objetivos del trabajo y evitar estas situaciones.

¿Cómo tener una reunión retrospectiva de Scrum eficiente?

Existen innumerables métodos para hacer una retrospectiva de Scrum, pero necesita conocer algunos roles y reglas esenciales para que funcione.

Roles y participantes

Facilitador: La persona que actúa como facilitador dicta el flujo de la reunión , reorientando los asuntos irrelevantes, haciendo preguntas que invitan a la reflexión y monitoreando el tiempo. Tienes que ser una persona imparcial en la reunión, dirigiendo el asunto, pero sin participar.

Por mucho que crea que es más seguro asignar este rol a un gerente, Silvi cree que es mejor no hacerlo, porque la gente puede dudar en señalar los errores. “Lo ideal es tener a alguien fuera del equipo que sea imparcial.

Si esto no es posible, me gusta tener a alguien de nivel junior o intermedio, para que tenga la oportunidad de desarrollar habilidades de liderazgo sin la responsabilidad del poder jerárquico ”.

Participantes: La retrospectiva no debe ser una reunión «abierta para todos». Solo aquellos que realmente necesitan estar allí deberían estar. Silvi también recomienda que los líderes senior no estén presentes para que nadie se sienta incómodo hablando de errores.

Otras reglas para el éxito:

• No use un teléfono celular o una computadora portátil . Todos deberían concentrarse en la conversación.
• No tome notas, excepto para definir planes de acción de equipo para el próximo Sprint.
• Esto es importante: no señalar con el dedo tratando de encontrar a los culpables.

A Silvi le gusta comenzar sus retrospectivas recitando “The Prime Directive” (en portugués: “The Principal Directive”), un tipo de credo creado por Norm Kerth, consultor de software y autor:

“No importa lo que descubramos, entendemos y realmente creemos que todos hicieron lo mejor que pudieron, considerando sus conocimientos en ese momento, sus habilidades, los recursos disponibles y la situación que enfrentaron”.

Silvi les pide a todos en la habitación, uno a la vez, que confirmen en voz alta que está de acuerdo con esa afirmación. “Nadie quiere que nadie señale con el dedo. Queremos que todos crean que todos estamos tratando de mejorar ”.

Asegurarse de que todos en la reunión asuman las mejores intenciones significa que todos tienen un enfoque positivo de la conversación.

Decidir el tema

Un error común (además de culpar) en las reuniones retrospectivas de Scrum es intentar hacer demasiado. Inevitablemente, su equipo querrá mejorar una larga lista de procesos, pero tratar de arreglar a todos en un Sprint no es nada realista. Su equipo debe decidir en grupo cuál es el único elemento con el que quieren lidiar y cómo solucionarlo.

El método preferido de Silvi para lograr este objetivo es un proceso llamado “mapeo mudo”, que limita a 30 minutos para continuar con la reunión. Cada miembro del equipo lleva un bloc de notas (tipo Post-It) para anotar observaciones sobre el Sprint, como una cara feliz, triste o confundida en cada nota. “Una cara feliz puede ser algo como ‘Me gustó cómo colaboramos en esta tarea’”, dice Silvi. “Una cara triste puede indicar algo que no salió muy bien: ‘No hemos llegado a un consenso sobre la implementación’. Una cara confundida puede decir: ‘No sé por qué esto no funciona’ ”.

Luego, el equipo trabaja en conjunto para dividir las notas en categorías. Si tres Post-Its son sobre comunicación en equipo, estarían juntos. Entonces, Silvi le pide a cada miembro del equipo que vote por la categoría que quiere abordar en el próximo Sprint. Midió esto entregando tres pegatinas a cada persona, que utilizan para «votar» sobre la categoría que más quieren discutir.

“Es importante que el equipo vote por una categoría que se pueda abordar y resolver”, advierte Silvi. «Una vez me uní a un equipo que votó por algo sobre lo que no tenían control, y pasamos un tiempo hablando sobre cómo resolver algo que no pudimos resolver».

Debate

Tan pronto como cuente los votos, podrá prepararse para discutir el problema. La persona que actúa como facilitador tiene un papel importante en esta parte de la reunión, ya que los debates tienden a desviarse un poco del tema. Silvi usa los «cinco por qué» (escuchar una descripción de un problema y preguntar «por qué» cinco veces) para llegar a la raíz del problema.

«Estamos perdiendo el tiempo creando cosas que no eran necesarias».

«¿Porque?»

«Porque no sabíamos que no era necesario».

«¿Porque?»

«Porque no nos comunicamos con el equipo de producto antes de comenzar a trabajar». «¿Porque?» Etcétera.

Tras este ejercicio, Silvi utiliza una técnica denominada “embudo de coaching” para pasar del debate del problema a los pasos de acción:

• Empiece por el problema: «Estamos perdiendo el tiempo creando cosas que no eran necesarias».

1. Hable sobre el objetivo: «No cree funciones que luego deban eliminarse en Sprint».
2. Analice las opciones para solucionar el problema: «Es posible que necesitemos más detalles sobre las solicitudes de funciones».
3. Analice las mejores opciones.
4. Termine con un plan de acción: «Actualice el formulario de solicitud de funciones para incluir más detalles».

Cuando todos están de acuerdo con el plan de acción, los elementos se pueden registrar e implementar en el próximo Sprint, lo que ayuda al equipo a actuar con continuidad y agilidad.

Desde pequeños pasos hasta grandes mejoras

No puedes negarlo. Las reuniones retrospectivas en Scrum pueden ser intimidantes, especialmente si aún está aprendiendo el proceso. Esa grabadora K7 de las lecciones de música de mi infancia nunca se convirtió en la mejor parte de aprender un instrumento, pero me ayudó a mejorar más rápido. Y esa parte es divertida y gratificante.

Recuerde, no está tratando de resolver todos sus problemas a la vez. La belleza de Scrum es su mejora gradual. Al reparar continuamente artículos pequeños, su equipo es más feliz, más productivo y dedica menos tiempo a lidiar con dolores de cabeza recurrentes.

Silvi concluye con este consejo: «Si en cada Sprint se habla de solo un problema y solucionarlo, usted quedará impresionado por lo bien que el equipo va a convertirse con el tiempo».