Un caso para el vital, pero a menudo evitado, encuentro retrospectivo de Sprint
Quiero hablarles de las retrospectivas de sprint, pero primero tengo que contarles una historia sobre la autoevaluación.
Cuando estaba en 5º grado, empecé a tomar clases de saxofón (ríete todo lo que quieras, todos sabemos que es el instrumento más genial). Tuve un gran maestro, un viejo músico de jazz que se había retirado de sus días tocando en clubes para enseñar música. Me enseñó habilidades para la vida: Persistencia, lidiar con la decepción, prestar atención a los detalles. Pero la mejor lección que me enseñó fue el valor de la autoevaluación.
Un día, me pidió que comprara una grabadora (que todavía era una cosa en aquel entonces) y la llevara a mi siguiente lección. La semana siguiente, me grabó mientras tocaba una canción en la que habíamos estado trabajando durante semanas. Tan pronto como terminé, me dijo: «Está bien, vamos a escucharla».
Estaba confundido, sólo lo jugué, sé dónde lo estropeé. ¿Qué sentido tiene escuchar lo que acabo de tocar?
Pero aquí estaba el problema: lo que yo pensaba yo tocaba no estaba ni cerca de lo que yo realmente tocaba.
La grabación reveló todo tipo de errores. Notas amargas, cambios de tempo, falsos comienzos. Fue horripilante.
La grabadora se convirtió rápidamente en mi posesión menos favorita, pero su valor era claro para mí incluso en ese entonces: A veces lo que sabes con seguridad que es verdad, no lo es.
Y esa perspectiva vital que obtienes de la autoevaluación es la razón por la que necesitas reuniones retrospectivas de sprint si quieres que tu equipo de scrum se mantenga en sintonía y tenga éxito.
¿Qué es una retrospectiva de Sprint?
Una retrospectiva de sprint es básicamente esto: Al final de cada sprint, el equipo debe reunirse para discutir el proceso. ¿Qué funcionó? ¿Qué no funcionó? ¿Cómo podemos eliminar los obstáculos en el siguiente sprint? Antes de reunir a todos en una sala y ventilar sus quejas, es importante entender los papeles y objetivos de una retrospectiva de sprint.
Uno de los principios clave del desarrollo ágil es la idea de la mejora continua de la productividad del equipo. Cada sprint debería ser un poco más eficiente que el anterior. La única manera de hacerlo es entender dónde están las debilidades en su proceso e implementar estrategias para superarlas.
De ahí la importancia de una reunión retrospectiva.
Michael Silvi es un consultor principal de Stride, una empresa de consultoría de desarrollo de software en la ciudad de Nueva York. Lleva siete años ayudando a los equipos a implementar equipos Agile y Scrum, y hace hincapié en una estructura formalizada (en la que entraremos a continuación) para el éxito retrospectivo. A continuación, comparte su experiencia sobre la estructura, los roles y los objetivos de una retrospectiva de sprint eficaz.
¿Por qué se pasan por alto las retrospectivas?
Cuando era un estudiante aprendiendo a tocar el saxofón, odiaba la grabadora porque me obligaba a escuchar todos los feos errores que cometía. Las retrospectivas de Sprint harán lo mismo, y se necesita madurez y confianza para enfrentar tus errores.
«Tienes que estar en un ambiente de alta confianza», dice Silvi. «Estás aireando los trapos sucios, así que sin un alto nivel de confianza, muchos equipos evitan las retrospectivas».
También están las presiones del ciclo económico. Silvi dice que los equipos están bajo mucha presión para cumplir a tiempo, y por lo tanto creen que tomarse cualquier tiempo para hacer una pausa y reflexionar ralentizará el proceso. O tal vez el equipo ha intentado reuniones retrospectivas en el pasado, pero carecía de un proceso eficiente para aprovechar plenamente su potencial, y decidió que no valía la pena el tiempo.
Pero este pensamiento a corto plazo lleva a problemas a largo plazo.
«Si no te tomas el tiempo para hablar de los problemas, podría haber algún problema sistémico que estás ignorando y no llegas a la raíz del problema», dice Silvi.
Sin discutir los problemas con el proceso de trabajo de un equipo, estás obligado a seguir repitiendo los mismos errores. El simple hecho de examinar tu trabajo, identificar problemas y acordar una solución puede tener efectos profundos.
Silvi describe el trabajo con un equipo que esperó seis meses para implementar reuniones retrospectivas regulares. Continuamente se encontraban con los mismos problemas en cada sprint: «No teníamos suficiente asociación con el equipo de producto. Yo trabajaba en una historia y no tenía un contexto de por qué lo hacía; sólo me dijeron que hiciera un trabajo», dice. «Sin el conocimiento del producto, construí la cosa equivocada, hice más trabajo del necesario, y tuve que borrar ese trabajo para hacerlo bien».
Además de ser una pérdida de tiempo, las áreas problemáticas repetitivas son un asesino para la moral del equipo. Al celebrar reuniones retrospectivas, el equipo pudo construir esa relación de equipo de producto, añadir contexto a su trabajo y evitar estas situaciones.
Presentando una retrospectiva eficiente de Sprint
Hay varios métodos para organizar una retrospectiva de sprint, pero hay algunos roles y reglas clave que necesitarás para tener éxito sin importar lo que pase.
Roles y asistentes
Facilitador: El facilitador mantiene la reunión en pista, redirigiendo las conversaciones fuera de tema, haciendo preguntas orientadoras y vigilando el reloj. Debe ser una parte imparcial de la reunión, conduciéndola pero sin participar.
Aunque su instinto podría ser asignar este papel a un gerente, Silvi recomienda no hacerlo, ya que puede hacer que la gente dude en señalar los errores. «Lo ideal es tener a alguien fuera del equipo que sea imparcial. Si no puedes tener eso, me gusta tener a alguien de nivel junior o medio, ya que les da la oportunidad de desarrollar el liderazgo, pero sin el bagaje del poder jerárquico».
Asistentes: La retrospectiva no debería ser un tipo de reunión «abierta a todos»; sólo deberían participar aquellos que realmente necesitan para estar allí. Silvi también advierte que no se debe tener a los líderes principales en la sala, ya que la gente puede sentirse incómoda discutiendo los errores delante de ellos.
Otras reglas para el éxito:
- No hay teléfonos, ni portátiles. Todo el mundo debería centrarse en la discusión.
- Sin tomar notas, más allá de decidir los elementos de acción como un equipo para el próximo sprint.
- Y (esta es una grande) no asignar la culpa.
A Silvi le gusta comenzar las retrospectivas recitando «La Directiva Principal», una especie de credo creado por el consultor de software y autor Norm Kerth:
«Independientemente de lo que descubramos, entendemos y creemos verdaderamente que todos hicieron el mejor trabajo que pudieron, dado lo que sabían en ese momento, sus habilidades y destrezas, los recursos disponibles y la situación en cuestión».
Silvi recorre la sala y hace que cada miembro del equipo confirme audiblemente su acuerdo con esta declaración. «No quieres que la gente señale con el dedo. Quieres que todos crean que todos estamos tratando de mejorar.» Asegurarse de que todos en la reunión asumen una intención positiva significa que todos se acercan a la discusión desde un lugar positivo.
Decidir un tema
Un escollo común (además de asignar la culpa) en las reuniones retrospectivas es intentar hacer demasiado. Inevitablemente, habrá una larga lista de procesos que su equipo querrá mejorar, pero intentar arreglarlos todos en un solo sprint no es realista. Tu equipo necesita decidir como grupo un solo asunto y cómo arreglarlo.
El método preferido de Silvi para lograr este objetivo es un proceso llamado «mapeo silencioso», que limita a 30 minutos para mantener la reunión en movimiento. Cada miembro del equipo recibe una pila de notas adhesivas para escribir las observaciones sobre el sprint, junto con una cara feliz, triste o confusa en cada una. «Una cara feliz podría ser para algo como: ´Me gusta cómo hemos colaborado en esta tarea´», dice Silvi. «Triste podría ser algo que no salió tan bien, ´No estuvimos de acuerdo en la implementación´. Confundido podría ser «No sé por qué esta cosa no funciona».
A continuación, el equipo trabaja en conjunto para agrupar las notas en categorías. Si hubiera tres notas adhesivas que trataran de la comunicación del equipo, se agruparían. A continuación, Silvi hace que cada miembro del equipo vote sobre qué categoría tratar en su próximo sprint. Facilita esto dándoles a todos tres pegatinas, que usan para «votar» sobre la categoría que más quieren ver fijada.
«Es importante que el equipo vote en una categoría en la que realmente puedan hacer algo», advierte Silvi. «Una vez tuve un equipo que todos votaron sobre algo que no tenían control, y perdimos el tiempo hablando de cómo arreglar algo que no podíamos arreglar».
Discusión
Una vez que has contado los votos, estás listo para discutir un problema. El facilitador juega un gran papel en esta parte de la reunión, ya que las discusiones de grupo tienden a salirse del tema. Silvi usa «cinco porqués» -escuchando una declaración de problema y luego preguntando «por qué» cinco veces- para llegar a la raíz de un problema.
«Estamos perdiendo el tiempo construyendo cosas que no eran necesarias.»
«¿Por qué?»
«Porque no sabíamos que no eran necesarios».
«¿Por qué?»
«Porque no nos comunicamos con el equipo de producto antes de empezar el trabajo.»
«Por qué»
Y así sucesivamente.
Después de este ejercicio, Silvi utiliza una técnica llamada «embudo de entrenamiento» para pasar de la discusión del problema a los pasos de acción:
- Empieza con el problema: «Estamos perdiendo el tiempo construyendo cosas que no eran necesarias».
- Habla sobre el objetivo: «No se construyeron características que luego deban ser eliminadas en este sprint».
- Discutir las opciones para solucionar el problema: «Podríamos requerir más detalles en las solicitudes de características».
- Discutir las mejores opciones
- Termina con los elementos de acción: «Actualizar el formulario de solicitud de características para incluir más detalles».
Una vez acordados estos puntos de acción, pueden ser registrados e implementados en el siguiente sprint, ayudando al equipo a correr más suave y rápidamente.
Pequeños pasos para una gran mejora
No se puede negar: Las reuniones retrospectivas pueden ser intimidantes, especialmente si eres nuevo en el proceso. Esa grabadora de mis lecciones de música de la infancia nunca se convirtió en mi parte favorita para aprender un instrumento, pero me ayudó a mejorar, más rápido. Y esa parte es divertida y gratificante.
Recuerda, no intentas resolver todos tus problemas de una sola vez. La belleza del scrum es la mejora incremental. Arreglando continuamente los pequeños objetos, tu equipo será más feliz, más productivo y pasará menos tiempo lidiando con dolores de cabeza recurrentes.
Silvi nos deja con este consejo: «Si en cada sprint hablas de un solo problema y lo arreglas, te sorprenderás de lo bueno que puede llegar a ser tu equipo».
