A continuación se muestra una lista de posibles técnicas a utilizar y pasos a realizar en una Retrospectiva, en forma de videos cortos (en castellano, con subtítulos en inglés):

Artículos relacionados

• Retrospectiva – Sprint retrospective 
• Una retrospectiva ágil de Scrum
• Retrospectiva de estrella de mar (Starfish retrospective)
• Retrospectivas ágiles – Resultados del septimo encuentro ágil en Barcelona

En este encuentro se presentaron dos tipos de retrospectivas, a las que se llamaron “Express” (para iteraciones cortas, de 2-3 semanas) y “full equipe” (para iteraciones de 1 mes, releases, fin de proyecto o empresa).

• El servicio ofrecido al cliente, la calidad que percibe del producto.
• La productividad del equipo.
• La calidad interna del producto (que sea mantenible para poder crecer de manera sostenida).
• Qué es aquello que le molesta, qué no deja disfrutar al equipo en su trabajo.

• Es importante dedicar una parte de la retrospectiva a reconocer las cosas que se hacen bien, para no caer en el pesimismo y derrotismo. Respecto a la otra parte de la retrospectiva, la dedicada a las cosas que no funcionaron, en lugar de hablar de “cosas negativas” es conveniente hablar de “cosas a mejorar”.
• En lugar de buscar culpables, el equipo tiene que pensar qué parte del proceso de trabajo hay que cambiar para que el problema no vuelva a suceder.
• El Scrum Master es el “engrasador” que evita que se produzcan conflictos entre personas durante la retrospectiva. Identifica a tiempo que se está entrando en conflicto destructivo para pararlo.

• Soluciones paliativas, aquellas que tenemos que tomar para vivir mejor a corto plazo pero que no solucionan el problema de base.
• Soluciones “core”, aquellas que necesitan más tiempo pero que a medio plazo solucionarán el problema.

• Se empieza pintando en el whiteboard una línea horizontal que simboliza las 2-3 semanas de la iteración. Esto nos ayuda a recordar y situar los eventos más significativos que ocurrieron.
• En la parte superior el equipo escribe las cosas positivas que sucedieron: qué está funcionando, reconocimientos a personas, etc.
• En la parte inferior el equipo escribe los problemas a mejorar, los efectos negativos que estamos experimentando en nuestros objetivos (ver apartado “Objetivo de una retrospectiva”).
• Cada persona del equipo puede poner hasta 3 puntos positivos y negativos en cada evento.
• Primer shortlist: nos quedamos sólo con los 2 o 3 problemas que el conjunto del equipo está considerado más importantes en este momento (en el futuro pueden cambiar). Si es necesario, se puede registrar el resto de problemas para en el futuro comprobar si permanecen a lo largo de las iteraciones y para recordar que de manera explícita se decidió no hacer nada con ellos en esta retrospectiva.
• Nos preguntamos cuáles son las causas de estos problemas y hacemos el segundo shortlist: nos quedamos con las 2 o 3 causas más importantes.
• Pensamos en las acciones que puede solucionar estas causas y hacemos el tercer shortlist: nos quedamos con las 2 o 3 acciones que tienen un mejor ROI (esfuerzo a dedicar por beneficio a obtener). Notar que en principio NO ejecutaremos todas las acciones que hayan aparecido por que:
  • El principio de Pareto también aplica a los problemas de un proyecto, es decir, será suficiente con acometer acciones muy concretas sobre las causas que producen los problemas con más impacto.
  • No tenemos todo el tiempo ni recursos del mundo para arreglar todos los problemas de nuestro proyecto.
  • Tenemos que producir para nuestro cliente, no sólo dedicarnos a mejorar.

• Business plan incorrecto (especialmente por falta de conocimiento del negocio y falta de suficiente dinero inicial).
• Problemas con los socios.

• Un buen business plan es la hoja de ruta.
• El conocimiento del negocio es como el carné de conducir.
• El dinero inicial es la gasolina.

 

• Retrospectiva – Sprint retrospective
• Una retrospectiva ágil de Scrum
• Retrospectiva de estrella de mar (Starfish retrospective)
• Videos cortos sobre retrospectivas 

Autor: Gustavo Veliz Bernaola

Scrum se basa en la ejecución de pequeñas iteraciones de varias semanas denominadas Sprints donde el equipo va desarrollando los requisitos seleccionados al comienzo de cada una de esas iteraciones (en la reunión de planificación del Sprint). El cliente puede tener entregas del proyecto que incluyan los resultados de varios Sprints y, una vez finalizados, todos los ellos hemos terminado el proyecto.

• Se realiza un esfuerzo por integrar los requisitos desarrollados durante las últimas semanas para obtener un resultado compacto y demostrable al cliente final, lo cual revela numerosos problemas imprevistos y de calidad. Lo más importante aquí es que estos problemas se detectan por adelantado en las primeras iteraciones de desarrollo (Sprints), mientras que en un proyecto tradicional en cascada estos errores se detectarían al final y serían mucho más complejos de resolver.

• Irremediablemente se crearán soluciones temporales o, hablando más claro, parches. Estos parches estarán ahí en la demostración, pero su presencia obliga a preparar y planificar soluciones reales para el siguiente Sprint. El equipo se ve obligado a reservar el tiempo necesario para solucionar estos problemas, y eso ayuda a no encontrarse sorpresas no planificadas de última hora y el tener que hacer esos sobreesfuerzos de los que siempre nos estamos quejando.

• Las demostraciones obligan al pragmatismo y a la creación de un producto susceptible de ser entregado al cliente con el mínimo esfuerzo necesario. Otro aspecto que yo considero importante de las demostraciones es que los miembros del equipo no pueden ser "mega-creativos" y crear soluciones que les lleve meses ver la luz (caso aún posible, pero que de darse estaríamos ante proyectos en si mismos y requerirían Sprints propios). El miembro del equipo se debe centrar en desarrollar un requisito de manera pragmática y siempre pensando en tener algo que entregar, algo que se pueda demostrar. 

• Involucración por parte de los miembros del equipo. Personalmente creo que la demostración no debe ser realizada por única persona, sino que aquí el Facilitador (Scrum Master) debe actuar como simple maestro de ceremonias. Hacer que los miembros del equipo participen en la demostración les obliga a involucrarse más en la misma. El esfuerzo inevitablemente será mayor ya que no es lo mismo poner tú mismo la cara que el que la tenga que poner otro por ti.

• El efecto moral de ver que el proyecto avanza. En nuestro caso por ejemplo hacemos la demostración para toda la compañía. Vosotros ya sabéis como es el trabajo en una compañía medianamente grande. A menudo la mayoría de departamentos o equipos trabajan de manera independiente, y prácticamente el único contacto que tienen con el proyecto es para conocer los problemas que unos tienen con el trabajo de los otros. "¿Oye, cómo teníamos que integrar vuestra parte de producto con la nuestra?", "¡Este requisito no se ha hecho como esperábamos, estamos perdidos.", "Hay que hacer cambios corriendo, ahora mismo os hacemos una petición formal de cambios", etc.

• Visibilidad para el cliente. Teóricamente las demostraciones deberían incluir al cliente. En muchos casos esto no es posible físicamente, pero lo ideal es hacerlo. En nuestro caso por ejemplo, las demostraciones internas se trasladan a otro equipo que se encargará de repetirla con el cliente final, ya en sus oficinas. Con la demostración el cliente puede comprobar que se está progresando, lo cual en el mundo de los proyectos no es tan común, además de poder validar todos sus requisitos y sugerir cambios cuando sea necesario.

• Rotuladores o marcadores de colores para cada uno de los asistentes
• Post-its
• Pizarra blanca grande o papel tamaño cartulina
• Datos objetivos de los problemas del proyecto (lista de requisitos priorizada (Product Backlog), lista de tareas de la iteración (Sprint Backlog), gráficos de progreso del proyecto o de la iteración (Burndown Charts), métricas del proyecto, etc.)

Actividades

Puesta en escena (5′)

El facilitador explica el objetivo de la retrospectiva y enumera los diferentes pasos y tiempos que va a tener la reunión.

Qué ha funcionado bien (15′)

Una retrospectiva no sólo debe fijarse en la solución de problemas (podría quedar una sensación demasiado negativa de que las cosas no van bien), si no también hacer reconocimiento de las cosas que fueron bien e identificar las que hay que potenciar más.

Para «forzar» a que todo el equipo piense en las cosas positivas que sucedieron, el proceso se puede iniciar de la siguiente manera: cada miembro del equipo tiene que escribir en silencio un mínimo de 2-3 post-its con lo que funcionó bien. A partir de ahí, se van poniendo de pie, explicando su post-it, pegándolo y agrupándolos por tema.

Identificación de problemas (20′)

• El facilitador hace un resumen de los hechos, objetivos conseguidos (o no) y decisiones más relevantes del período o proyecto a analizar con la finalidad de mejorar en el siguiente. Se apoya en datos objetivos utilizando para ello, por ejemplo, la lista de requisitos priorizada, la lista de tareas de la iteración, las actividades realizadas, los gráficos de progreso del proyecto o de la iteración, las métricas del proyecto, etc.
• Los miembros del equipo proponen aspectos a mejorar adicionales, anotando los problemas en post-its que se pegan en una pared o una pizarra blanca de manera que todo el equipo pueda leerlas. Como base para identificar problemas se puede utilizar una línea de tiempo del proyecto (cronograma de lo que sucedió).
• El equipo agrupa los diferentes problemas según tengan una afinidad o relación y da nombre a cada grupo, escribiéndolo como cabecera de grupo en la pizarra (o bien utilizando para ello un post-it.
• El equipo vota qué grupos de problemas afectan más a los objetivos del proyecto o la productividad del equipo. Para ello cada persona dispone de hasta 5 puntos en forma de post-its a repartir libremente entre los diferentes grupos.

Descubrimiento de causas (20′)

• Para los grupos de problemas más votados, el equipo analiza por qué se están produciendo. Para ello utiliza, por ejemplo, un diagrama de espina de pez o Ishikawa, con el problema como espina dorsal y las causas como espinas que crecen a partir de la dorsal o de otras causas, hasta encontrar las causas básicas.
• Notar que en ningún momento se trata de buscar culpables, si no de ver qué partes del proceso de trabajo, de interrelaciones y de colaboración, tanto intraequipo como con terceros, deben ser mejoradas.

Plan de acción (15′)

• El equipo propone soluciones para las causas que producen la mayoría de los problemas del proyecto. Para ello puede utilizar una lluvia de ideas. Su selección final puede estar basada en una votación o en criterios como coste, esfuerzo o tiempo de realización, satisfacción del cliente, sostenibilidad de la solución, etc.
• Se generan las tareas necesarias y en ese momento las personas ya se autosignan la responsabilidad de ejecutar, o bien las tareas se introducen en un Improvement Backlog o la lista de tareas de la siguiente iteración (Sprint Backlog).

Conclusiones de la reunión (15′)

• Se revisan las principales conclusiones y decisiones.
• Se revisa si se ha conseguido el objetivo de la reunión.
• Se analiza qué ha ido bien y qué hay que mejorar de la dinámica de la retrospectiva para que la próxima sea mejor (¡ la retrospectiva de la retrospectiva !).

Artículos relacionados

• Retrospectiva – Sprint retrospective
• Retrospectiva de estrella de mar (Starfish retrospective)
• Retrospectivas ágiles – Resultados del septimo encuentro ágil en Barcelona
• Videos cortos sobre retrospectivas