5 reglas para las retrospectivas

Jueves 04 de Marzo de 2010 17:06 Escrito por Leonardo De Seta

A punto de sentarme junto a mi equipo para otra retrospectiva, estuve leyendo y analizando
algunas notas de retrospectivas anteriores en las que participé. Y mirando muchas de estas notas,
especialmente de las malas, empecé a darme cuenta de algunos patrones de comportamiento que
pueden ayudar o destruir una retrospectiva. Veamos los puntos más importantes.
1. La retrospectiva es del Equipo
Este quizás sea el punto más importante: las retrospectiva sólo son efectivas si realmente le
pertenencen al equipo. Esto significa que sólo el equipo debería asistir, y sólo el equipo puede
elegir objetos y decidir cómo seguirlos. La gerencia no debería asistir ya que podría ocasionar
interferencias, interrupciones, o pedir que se generen métricas. En muchas retrospectivas a las
que asistí estaba presente un gerente que interrumpía a las personas, o les decía que el objetivo
que se proponían no iba a funcionar y les impedía considerarlo. Estas retrospectivas eran las más
inútiles porque nunca se lograba nada.

2. No dejar que se convierte en una reunión de quejas

Las retrospectivas son sobre inspeccionar y adaptar... sobre mirar nuestras experiencias en el
pasado y usar análisis de causa raíz para encontrar causas sobre cómo mejorar el futuro. Sin
embargo, si en el pasado ocurrieron muchas cosas negativas, podemos caer en "llorar por la leche
derramada" sin llegar a soluciones reales. Y no hay nada peor para el equipo que perder una hora
escuchándose entre ellos sin ninguna actividad constructiva: desmoraliza en vez de motivar. Por
lo tanto, debemos apuntar a mantener la retrospectiva sobre hechos y observaciones, y hacer
énfasis que el pasado sólo sirve para sacar experiencia concreta de la cual sacar ideas. Las
actividades de resolución de problemas deberían tener más foco que llorar sobre los datos
históricos.

3. Las actividades son mejores

Asistí a cientos de retrospectivas, con y sin actividades. Parecería que las retrospectivas directas,
del tipo "hablar de lo que funcionó, lo que no funcionó, y qué mejorar", son simples y van al
grano. Sin embargo, mi experiencia me dice que estas retrospectivas también son las menos
efectivas. Las personas siguen con la mentalidad "esto es una reunión" que les impide pensar
activamente.
En general las actividades hacen que las personas se involucren más. En una reunión cualquiera
podría estar sentado mirando un proyecto (pensando en cualquier cosa), mientras que con las
actividades están constantemente involucradas y no tienen tiempo para desconectarse. Además, la
informalidad misma de las actividades ayuda a que las personas superen ciertas barreras
comunicacionales, y les resulta más facil decir lo que piensan.
4. Eligir sólo 1 objetivo
En teoría suena bien elegir varios objetivos, ¿no? Identificamos todos estos impedimentos y
bloqueos que se interponen en el avance del equipo, o situaciones del entorno que necesitan
resolverse. ¿Por qué no atacar TODOS estos temas en vez de ignorarlos, y así trabajamos en
quitarlos todos juntos? Esta forma de pensar es de la misma escuela de "maximizar el trabajo-en-
progreso maximiza la eficiencia"... y todos sabemos que en general esto falla. De la misma
manera, si maximizamos la cantidad de objetivos que tomamos en una iteración, corremos el
riesgo de tener que cambiar de contexto muy seguido (sin mencionar el foco que ya necesitamos
para el trabajo que estaremos haciendo en la iteración), que el equipo pierda su camino y
posiblemente no pueda completar ninguno de los objetivos planteados.
Por lo tanto, como equipo debemos limitar el trabajo-en-progreso y elegir un objetivo (y sólo
uno) para que el equipo trabaje en la próxima iteración. Quizás lo completen en 1 día. Quizás lo
completen al terminar la iteración. Quizás avancen en el tema y descubran en la próxima
iteración que hay problemas más profundos que tienen que resolverse.

5. Seguimiento
Uno de mis mayores errores como facilitador fue no poder ayudar a los equipos a que sigan sus
objetivos... asumía que podía dejar al equipo para que forme su objetivo, discuta cómo
alcanzarlo, y después dejar la habitación para que se agende la próxima iteración. Qué
equivocado que estaba. Al trabajar en un objetivo es posible que se enriquezcan retrospectivas
futuras, además de poder descubrir problemas más profundos que necesitan resolverse. Si no hay
seguimiento, puede ocurrir que el equipo termine con un grupo de objetivos que nunca completan
o que son superficiales. Entonces, es bueno reflexionar sobre el objetivo que se formó al inicio de
una retrospectiva, y ver qué ideas nuevas aparecen, o analizar porqué no pudo cumplirse. A
menudo podemos encontrar que los objetivos incumplidos tienen relación con la iteración... por
ejemplo, si no se alcanzó un objetivo porque no hubo suficiente tiempo, ¿quizás la iteración no
tenga el tiempo necesario para hacer estas cosas?

Resumen
De todos estos puntos, la más importante es la primera: la retrospectiva le pertenece al equipo.
Es una actividad para el quipo, por el equipo, para ayudarlos a inspeccionar y adaptar sus
procesos, y no debería ser forzado o liderado por un gerente. El facilitador de la retrospectiva
tiene que recordar su posición: no es un gerente y por lo tanto no tiene que dictarle objetivos al
equipo. El facilitador debe mantener una postura neutral, nunca hacerse dueño de una solución, la
cual debe pertenecer al equipo, quien necesita asegurarse de hacer lo necesario para que ocurra.
Si tienen que agendar una tarea en la iteración, hay que dejar que ellos mismos lo hagan.
Por lo tanto, como facilitador debemos darle suma importancia a mantenernos neutrales. Cuando
facilitamos equipos debemos evitar involucrarnos. También debemos recordar que como
facilitadores nuestra trabajo es facilitar la discusión, no dirigir u ofrecer soluciones.
En resumen, recordemos que las retrospectivas son para encontrar soluciones, no problemas.
Mantengamos el rumbo, escuchemos, y guiemos a los equipos a verse a si mismos y a encontrar
las soluciones que necesitan. Lo más importante es que la retrospectiva sea su actividad para
mejorar y tomar decisiones.
Traducido de Retrospective rules, por James Carr.

6 Secretos para retrospectivas exitosas

Jueves 02 de Julio de 2009 09:15 Escrito por Diego Gomez
Este post es un relato de la presentación realizada en el Scrum Gathering Brasil.Esta presentación
fue hecha por Boris Gloger, un alemán muy famoso en la escena de scrum y responsable de la
formación de muchos CSM en Brasil. Él dispensa presentaciones, excelente contenido, algunas
cosas divertidas y con óptimos slides, vale la pena la conferencia!
Pasó a través de varios aspectos importantes en una retrospectiva. Fue una presentación que
exploró bien este asunto importante para que el equipo evolucione, aunque no es una cuestión
siempre valorada.
¿Qué es retrospectiva?
Retrospectiva es el proceso de aprender del pasado para el futuro. Las retrospectivas no formaban
parte de Scrum en su principio, pero en 2004 se convirtió en una práctica. Varios profesionales
tienen este tipo de procedimiento, después de una acción: los bomberos hacen "Ater Action
Review", los militares hacen "debriefing", para nombrar unos pocos ejemplos.
Cuando no se está usando scrum correctamente o cuando no se tiene tiempo suficiente, lo
primero que se deja de hacer son las retrospectivas. Pero esta sesion es fundamental para la
mejora. En la anterior conferencia, Rodrigo de Toledo, también concordaba con esto, dijo que si
tuviera que elegir lo mínimo que un proceso de desarrollo debe tener, sería el hecho de ser
iterativo y hacer retrospectivas.
Una objeción común a estas reuniones de retrospectiva es que estamos muy bien, no necesitamos
mejorar. Pero, en realidad, en las retrosectivas debemos encontrar qué hacer para no dejar que
sean molestas, para que no paren y seguir haciendo bien las cosas. Es una buena oportunidad para
pensar en cual es nuestro siguiente paso importante, para dónde vamos.
¿Qué es el aprendizaje?
Antes de continuar, Boris conceptualizó lo que es el aprendizaje. Y planteó las siguientes
cuestiones:
¿Por qué los adultos dejan de aprender? Los niños todavía aprenden, es divertido para ellos. Un
buen ejemplo para ello es el secreto de la gravedad. Cuando el niño está jugando insistentemente
deja caer una cuchara al suelo, él está aprendiendo lo que es la gravedad. En primer lugar, los
niños aprenden de la repetición.
Luego, aprende con la decepción de las expectativas. Y esto sucede con los globos de gas. Los
niños liberan los globos pensando que va a suceder lo mismo que ocurrió con la cuchara, pero no!
El globo va para arriba! Cuando nos sentimos decepcionados, aprendemos. Cuando somos
adultos, en lugar de decepcionarnos, culpamos al ambiente, a los demás y dejamos de aprender.
Es importante que las personas tengan seguridad psicológica para tener una buena retrospectiva.
Es preciso que las personas correctas estén presentes, sin enemigos, para crear un ambiente de
seguridad psicológica. Cuando las personas tienen metas altas y seguridad psicológica ellas se
encuentran en una zona de aprendizaje. Si tuvieran metas altas y baja seguridad psicológica están
ansiosas. Y con alta seguridad y bajas metas lo que tenemos es una zona de confort.
¡Llama al médico!
La retrospectiva es como un diagnóstico. Usamos una herramienta para examinar lo que el
paciente tiene. Una madre al ver que su hijo está resfriado, a menudo más allá del diagnóstico,
reta al niño por haber caminado descalzo, haber tomado cosas frías y no haber oído lo que ella
decía. Ella hace el diagnóstico y el reto. En la retrospectiva, nos tenemos que comportar como un
médico, imparcial, haciendo el diagnóstico y queriendo saber lo que pasa. La mejor herramienta
para la retrospectiva es el propio equipo charlando, sentados juntos y viendo cómo se puede
mejorar.
¿Cómo ejecutar una retrospectiva?
Contar historias. Usar cuentos para transmitir los acontecimientos del pasado para el futuro. El
equipo debe contar historias para el propio equipo. Contando "casos" del pasado para garantizar
que el mensaje se transmita.
Tengamos cuidado. Los adultos comenzamos a culpar a las personas. El facilitador de la revisión
debería garantizar que el equipo entiende que no es encontrar culpables. Un libro excelente sobre
el tema es Project Retrospectives. Independientemente de lo que se descubrió, nosotros debemos
comprender y, realmente creer que todos hicimos el mejor trabajo que podíamos, dado lo que
sabíamos en el momento, de acuerdo con nuestros conocimientos y habilidades.
Contemos historias Observemos y recojamos hechos del pasado:
* Hagamos un timeline de lo que sucedió en el sprint, enumerando hechos importantes.
* Recojamos artefactos del pasado.
* O hagamos algún tipo de juego, que toque el tema de lo que pasó.
¿Qué salió bien? (¿What Went Well?)
No sólo es para ver lo que estaba mal en el pasado, también es para ver lo que queremos
mantener. Como los facilitadores, debemos hacer que el grupo mire al pasado y vea lo que quiere
conservar.
¿Qué queremos cambiar para el futuro?
Después de lo que fue bien, vamos a centrarnos en el futuro. Tomemos todas las ideas que el
equipo tiene para mejorar. Luego, dividamos las ideas entre responsabilidades equipo/scrum
master y dueño del producto/empresa. Ordenemos estas ideas de las más importantes hasta las
menos importantes. Es muy recomendable trazar un plan de acción.
La planificación del sprint es un buen punto de partida para las ideas de mejoras del equipo.
Entonces ¿las mejoras van siempre al backlog? No! El equipo decide! El equipo hará lo que
piensa que es correcto.
Pero, ¿qué será mejorado? ¿Quién define? El equipo mejora lo que ellos quieran mejorar.
Pero y si la mejora que creamos impacta en alguien más? ¿qué hacemos? Conversemos!
Resumiendo lo que debe tener una retrospectiva
* Crear seguridad para el equipo
 * Contar una historia sobre lo que sucedió
* ¿Lo qué fue bien?
* ¿Lo qué fue mal? Dividido entre empresa y equipo.
* Prioricemos lo que se hará y hagamos algo concreto y medible
Muchos hacen la retrospectiva fuera de la empresa, esto no es esencial, mas no lo haga en el
mismo lugar de trabajo del equipo. Y no deje que la retrospectiva dure mucho, debe durar menos
de 90 minutos. Si desea sesiones mayores, es importante prepararlas muy bien.
¿Quién participa de la retrospectiva? Quien el equipo desee. Si vemos que una retrospectiva no
va bien, veamos si no tiene gente de fuera del proyecto, muy posiblemente no le está haciendo
bien.
Y, finalmente, el Scrum Master debe actuar, tiene que hacer que las cosas ocurran. El Scrum
Master debe actuar si ve que algo no está bien.
En conclusión ...
Una retrospectiva debe ser divertida. Cambiemos, innovemos, cambie de ubicación. Tiene que
ser algo divertido! Estemos atentos porque muchas veces las personas están asustadas en culturas
que las dejan aprender.
Basado en 6 Segredos para Executar Retrospectivas de Sucesso