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).
Se expuso la conveniencia de utilizar el principio de Pareto en la resolución de los problemas de un proyecto, es decir, unas pocas causas producen los problemas con más impacto. Por ello, y para ser más efectivos en las retrospectivas, se consideró de especial importancia ir haciendo “shortlists” de los resultados de las actividades típicas (identificación de problemas, causas y soluciones).
Se hizo una simulación de retrospectiva “full equipe”. Se partió de un “blind brainstorming” para decidir el tema a tratar (“Nuevos negocios, la mayoría mueren en el primer año”).
Se señalo la importancia de transmitir el conocimiento generado en las retrospectivas al resto de equipos y se finalizó haciendo una retrospectiva del encuentro.
Objetivo de una retrospectiva
NO se está haciendo Scrum, no se puede ir mejorando de manera continua, si regularmente no se dedica un tiempo de calidad para que el equipo reflexione sobre cómo está trabajando y aprenda a ser más efectivo y eficiente, todo ello disfrutando de su trabajo. Es decir, el equipo debe ir mejorando de manera gradual respecto a:
- 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.
Si no se dedica 1 o 2 horas cada 2 semanas (o 3 o 4 horas al mes) a hacer retrospectivas, los problemas se repetirán iteración a iteración, lo cual producirá frustración en el equipo.
Enfoque constructivo y positivo
- 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.
Tipos de acciones de mejora
Las acciones de mejora que se identifican en una retrospectiva se pueden dividir en dos grupos:
- 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.
Dependiendo de su alcance, las acciones de mejora se incorporan a los sprint backlog de las siguientes iteraciones y/o a la lista de impedimentos del Scrum Master.
Ayuda externa
En la retrospectiva el equipo puede verse limitado en su capacidad para dar soluciones. Dado que siempre “golpea” de la misma manera, con el mismo martillo, el equipo puede encontrar como solución la participación de algún experto externo que les ayude en su trabajo, e incluso que acuda a la retrospectiva para ofrecer alternativas.
Retrospectiva Express
- 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.
Poco a poco, iteración a iteración, iremos arreglando los problemas más importantes que vayamos encontrando en cada momento.
Retrospectiva “full equipe”
Se hizo una simulación de retrospectiva “full equipe”. El tema se eligió haciendo un “blind brainstorming”: para que nadie se sienta cohibido con su propuesta respecto a los demás, las propuestas se escribieron de firma anónima en papeles. Tras hacerse públicas, se agruparon y se votaron para ver cual era la más interesante para todos.
El tema elegido fue: “Nuevos negocios, la mayoría mueren en el primer año”.
Las causas que se identificaron fueron:
- Business plan incorrecto (especialmente por falta de conocimiento del negocio y falta de suficiente dinero inicial).
- Problemas con los socios.
Alexis Roqué hizo la siguiente metáfora:
- 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 de la retrospectiva
Siguiendo el principio de “inspeccionar y adaptar”, para ir aprendiendo a hacer retrospectivas, al final de cada una se hace una retrospectiva de la retrospectiva.
En el caso del encuentro, lo que más gustó fue haber podido practicar lo que se había explicado (una retrospectiva), que la gente se soltó, participó, que hubo un buen dinamizador, lo sencilla que era la retrospectiva Express, la idea de cortar y simplificar (“shortlistear”) en todas la actividades de la retrospectiva y el haber hecho timebox de las actividades del encuentro.
En lo que hay que seguir enfocándose es en tener encuentros menos teóricos y más prácticos.
Gestión del conocimiento
Es importante transferir el conocimiento adquirido en una retrospectiva (las “best practices”) al resto de equipos, para tener una mejora continua de la organización.
Por ello hacemos estos resúmenes 😉
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas.
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona
Artículos relacionados
Proyectos Ágiles 
El post ya tiene sus años, pero la metodología de la retrospectiva express me ha servido para una retro con vacaciones de por medio. La podéis ver en https://wp.me/p8OsPK-4Q .
¡Gracias y enhorabuena!
Me gustaMe gusta