Excelente post de un gran amigo y agilista :
Leonardo Agudelo (@sweepnoise)
http://agilescolombia.org/2015/02/12/buenas-retrospectivas-equipos-en-mejoramiento-constante/
La copio pues la considero de colección.
---------------------
Desde hace algunos días he tenido la oportunidad de facilitar retrospectivas de varios equipos y la experiencia obtenida merece ser compartida.
Los equipos a los que facilité la retrospectiva no necesariamente tenían como costumbre hacerlas con una frecuencia definida, otros tenían bastantes problemas cuando las realizaban y otros ya no las hacían… en fin… había necesidad de cambiar la estrategia.
Me basé en la estructura recomendada en el libro “Agile Retrospectives: Making good teams great” para planear las retrospectivas, la cual cuenta con los siguientes puntos:
- Preparar el escenario: lograr que las personas se focalicen en los objetivos de la reunión, en el tiempo estipulado y con una dinámica productiva.
- Conseguir datos: lograr una visión común de la situación a analizar, tanto con datos objetivos como subjetivos. Es la base común de hechos, eventos, sentimientos que permitirá tener una comunicación efectiva el resto de la reunión.
- Generar entendimiento profundo: entender el por qué, tanto de lo que anduvo mal como de lo que anduvo bien. Ir más allá de la primera apariencia, para encontrar las causas profundas que hay que sostener y mejorar o cambiar.
- Decidir qué hacer: teniendo una lista de posibles experimentos que el equipo puede realizar para mejorar, es el momento de elegir, ya que no todo se puede hacer para el siguiente sprint.
- Cierre: finalizar claramente la retrospectiva, con una nota positiva y ganas de realizar los experimentos que se encontraron.
Complementé estos pasos con otros dos que me recomendó un entrenador muy reconocido en el continente (Alan Cyment):
1.1 Revisar los compromisos adquiridos en la retrospectiva pasada
2.1. Priorizar los datos
Estos dos puntos adicionales me parecen vitales, ya que por un lado es una mala práctica (o antipatrón) de retrospectiva no revisar los compromisos adquiridos en retros anteriores, y tratar de cubrir todos los temas que afloran en medio de la retrospectiva es ineficiente.
Usé en cada una de las etapas de la retrospectiva actividades o dinámicas que facilitan e incentivan la participación de los miembros del equipo. Me parece que se pueden recomendar las siguientes:
Para preparar el escenario: la actividad “Histograma de satisfacción” . Cada participante selecciona el nivel de satisfacción en el sprint que termina desde un punto de vista general y lo explica al resto del equipo. Los niveles son:
- 5- Somos los mejores del mundo! Qué gran equipo que somos!
- 4- Estoy orgulloso de ser parte del equipo y de cómo trabajamos.
- 3- Bastante satisfecho, trabajamos bien juntos la mayoría de las veces.
- 2- A veces estoy satisfecho, pero pocas.
- 1- Estoy disconforme y poco satisfecho con el nivel de trabajo en equipo.
Se debe revisar el avance 2 o 3 iteraciones después
Nota: para esta actividad es importante tener un timebox de 2 minutos para que cada explique lo que lo llevó a elegir su nivel, de lo contrario se convierte en el paso 2 de la estructura de retros, que es conseguir datos.
Para Conseguir los datos: me pareció muy buena la actividad Mad, Sad, Glad (Enojado, Triste, Alegre), en esta actividad cada participante identifica en 7 minutos todos los momentos que le causaron esas sensaciones y los escribe en postit, (uno por postit), luego los expone al grupo. Esta actividad promueve el uso de frases “Yo”, ya que pone de antemano el sentimiento que le generaron al participante diferentes situaciones o momentos durante el sprint y evita el señalamiento y atribución de culpas.
Nota: los mensajes “YO” son así:
Cuanto tu (establezca el comportamiento)
Me siento (establezca el sentimiento)
Entiendo lo que sientes (empatice con el otro)
Porque (establezca consecuencia)
Te pido el favor de (establezca la petición, negocie el cambio)
Para generar entendimiento profundo: ensayé dos formas, la técnica de 5 por qué’s, la cual facilita la búsqueda de las causas reales de un problema al preguntarle al grupo ¿Por qué? reiterativamente, se supone que tras 5 respuestas ya hay un entendimiento más profundo. Esta técnica es buena, pero me pareció mejor la espina de pescado (diagrama de Ishikawa), esta permite hacer un análisis causal sin perder de vista algunos aspectos de la discusión que se pierden fácilmente con la técnica de los 5 por qué’s. Es muy importante que el equipo ponga los porcentajes de aporte al problema de cada rama del diagrama.
Para decidir qué hacer: la mejor forma que he visto es una lluvia de ideas en parejas. En un timebox (pueden ser 7 minutos) se proponen actividades concretas, que se puedan asignar a alguien en el siguiente sprint. Luego de los 7 minutos cada pareja explica las propuestas y se van agrupando si se refieren a lo mismo que las propuestas de otras parejas. Finalmente se permite que cada persona vote por las ideas que más le gustan. A cada participante se le dan 5 puntos, los cuales pueden ser distribuidos como quiera entre las propuestas. Las 3 o 4 propuestas que tengan más votos serán las que el equipo se asigne.
Es muy importante que las actividades ganadoras tengan un doliente que se encargue de que sucedan (no necesariamente son quienes las ejecutan).
Para el cierre: ha funcionado bien una sesión de agradecimientos, donde cada persona le expresa al resto del equipo a quién le agradece y por qué.
Estas actividades han dado muy buenos resultados, pero es muy importante variarlas, en la siguiente dirección se pueden obtener cerca de 2 millones de retrospectivas diferentes:
http://www.plans-for-retrospectives.com/index_es.html , esto es, contando las posibles combinaciones de diferentes actividades para cada etapa. Así que no hay excusas para no variar las retros.
Una ventaja para resaltar al usar la estructura propuesta es que con ciertas actividades hay mayor participación de personas que nunca participaban en las retros con otra estructura, alguna vez alguien me dijo “… este nunca hablaba…”, lo cual es bastante gratificante.
Otra cosa que me parece muy buena es que el mismo equipo es el que logra identificar sus problemas y proponer las soluciones, como facilitador solo aporto cuando veo que hay un concepto de agilismo que no está totalmente claro, y así yo crea que tengo la solución para un problema que viven ellos, me lo guardo y espero que encuentren sus propias soluciones. La tentación es grande, porque solemos creer que tenemos la respuesta para todo, pero los mismos equipos son los que sufren los problemas y ellos deben encontrar sus salidas, creo que esto fortalece la noción de autogestión y de compromiso del equipo, parte esencial de los equipos de alto desempeño.
Me parece que hay un riesgo que se debe manejar y es que las actividades que se eligen y para las cuales queda alguien responsable no se lleven a cabo. Cuando esto sucede la sensación en la siguiente retrospectiva puede ser que no sirve para nada hacer la retro. Para mitigar esto es bueno poner las tareas en el tablero Kanban, tal como las actividades de desarrollo y no perderlas de vista durante el sprint.
Como siempre digo en los entrenamientos, si un equipo no hace retrospectivas es como si dijera: “Somos perfectos, ya no hay nada que podamos hacer para mejorar”, lo cual es una mentira. Siempre hay forma de mejorar, de buscar la excelencia, de permanecer en el camino de la mejora continua.
