Retrospectiva

Es una reunión que realiza el equipo regularmente para reflexionar juntos y buscar acciones de mejora sobre su manera de trabajar juntos, independientemente del producto. La Retrospectiva es la técnica más poderosa que aporta el agilismo al desarrollo de equipos porque les permite reflexionar de manera regular y buscar acciones de mejora concretas que, por pequeñas que sean, siempre suman.

¿Para qué sirve?

Cada vez que nos detenemos durante un proyecto para realizar una retrospectiva, estamos buscando la mejora continua o “kaizen”. También podemos verlo como el momento para “afilar el hacha” (de la metáfora del leñador).

¿Cómo se hace?

Se reune todo el equipo. Es el momento donde es más necesario un buen facilitador pues se trata de crear el clima de confianza necesario para que todos los miembros del equipo colaboren en averiguar:

  • qué deben seguir haciendo (porque funciona)
  • qué hay que dejar de hacer (porque no funciona)
  • qué se puede experimentar (porque quizás sirva para mejorar)

Se puede simplificar usando sólo pluses y deltas, pero hay que esforzarse en no dejar que las deltas sean sólo quejas.

Es importante no perder tiempo en buscar explicaciones ni justificaciones. Lo importante es obtener el mayor número de ideas posibles en un tiempo corto. Si no se hace así es muy fácil llegar a que la retrospectiva se convierta en un cruce de acusaciones o a un muro de las lamentaciones. Es importante que nadie se quede sin hablar, que no haya personas que monopolicen la discusión y, sobre todo, que no haya discusiones personales. Buscamos la autocrítica para mejorar como equipo.

Se revisa la retrospectiva anterior y se aprovecha para añadir a la lista todo aquello que no se hubiera resuelto con éxito durante la iteración.

A continuación el equipo elige las ideas más relevantes sobre las que centrar la discusión. Nos interesan especialmente las posibilidades de mejora. Se puede conseguir fácilmente haciendo que el equipo se levante, agrupe los asuntos por afinidad y, si es necesario, que vote (p.ej. dot-voting).

Empezando por los “deltas” más votados, se exploran conjuntamente las causas y se proponen acciones. Hay que evitar buscar justificaciones y centrarse en buscar maneras de mejorar, lo cuál no quiere decir que no se pueda discrepar. La retrospectiva es el momento para hacerlo.

Es fundamental salir de la retrospectiva con unas pocas acciones para mejorar (muchas acciones no es práctico) y responsables de que éstas se realicen.

No hay límite de tiempo, pero como en toda reunión, más de 2 horas no es conveniente. En la práctica he observado que menos de una hora es improductivo porque no se consigue profundizar lo suficiente en los temas importantes.

Otro tipo de retrospectivas:

  • retrospectivas “arqueológicas”, a las que se llevan datos como los builds rotos, el uso del control de versiones, la cobertura de los tests…
  • “post-mortem” o autopsia que se hace al final de un proyecto y a la que se puede invitar a más gente de la habitual

Bibliografía:

Enlaces:

  • Retrospective wiki
  • Plans for Retrospectives (también conocido como Retro-O-mat) permite seleccionar diferentes técnicas para cada una de las fases descritas en el libro de “Agile Retrospectives”. (También hay una versión impresa).

PUBLICIDAD:

Si estás interesado en contar con mi ayuda para facilitar una retrospectiva o recibir formación, puedes leer sobre los servicios que ofrezco o ponerte en contacto conmigo.

One Pingback/Trackback