h1

Agile Retrospectives: Making Good Teams Great

02/07/2012

Wizbook [Icon By Buuf]  Libros.

Retrospectiva es el proceso de aprender del pasado para mejorar el futuro.

Boris Gloger, primer Scrum Trainer certificado por la Scrum Alliance. Scrum Gather Brazil, Mayo 12, 2009.

La semana pasada terminé de leer el libro Agile Retrospectives: Making Good Teams Great de Esther Derby y Diana Larsen. El libro es prácticamente un recetario con técnicas específicas que ayudarán a los equipos ágiles llevar a cabo retrospectivas más eficaces. El texto es extraordinariamente concreto y posee algunos ejemplos que ayudarán a poner en práctica las técnicas mostradas. Sin embargo, a diferencia de otros ejemplares relacionados a metodologías ágiles, éste documento sólo describe en un par de líneas la finalidad de una técnica dada por lo que es apta para principiantes, pero para quienes queremos ahondar en el tema, será necesario recurrir a otras fuentes.

Los tres primeros capítulos definen la estructura general que una retrospectiva debe poseer:

1. Sentar las bases: definir los objetivos, tiempo y resultados esperados de la retrospectiva.
2. Recopilar información: encontrar lo ‘bueno’, lo ‘malo’ y lo ‘feo’ que ocurrió durante la iteración actual.
3. Generar introspección (insights): por qué pasó lo que pasó.
4. Decidir qué hacer: definir qué se debe realizar para mantener lo que se hizo bien y evitar lo que se hizo mal.
5. Cerrar la retrospectiva: documentar la experiencia y generar un plan de acción.

En estos tres capítulos se muestran algunos tips generales relacionados a las retrospectivas: quién debería dirigirlas, cómo administrar el tiempo, cómo debe manejarse la dinámica de grupo. Por ejemplo, debido a la discusión llevada a cabo, puede que se desborden las pasiones, por lo que existe la posibilidad de que alguien termine por salirse de la reunión, molesto. Cuando ocurra esto, es necesario que el conductor de la retrospectiva lo deje ir, preguntando al resto del equipo “¿Qué es lo que acaba de ocurrir?” seguramente, ellos tendrán una noción del porqué. Entonces, se puede continuar con la retrospectiva sin la persona faltante y finalmente, ya fuera de la retrospectiva, hay que platicar con esta persona para que en forma más calmada nos explique qué es lo que pasó.

Con el cronómetro en la mano

De acuerdo a las autoras, una retrospectiva debe tomar en cuenta el tamaño de la iteración. Para un Sprint de una semana – el libro está muy orientado hacia Scrum, aunque no es indispensable conocerlo – una hora de retrospectiva será suficiente. Para Sprints de un mes, se requerirán cuatro horas para cubrir todos los objetivos propuestos.

Luego, el libro indica cómo debería estar repartido el tiempo entre cada actividad. Por ejemplo, para una iteración de dos horas, se definen los siguientes porcentajes:

Fase Porcentaje Duración
Sentar las bases 5% 6 min
Recopilar información 30 – 50 % 40 min
Generar introspección 20 – 30% 25 min
Decidir qué hacer 15 – 20% 20 min
Cerrar la retrospectiva 10% 12 min
Tiempo extra 10 – 15% 17 min
Total 100% 120 min
Fases, porcentajes y duración de cada fase durante una retrospectiva.

Los siguientes capítulos detallan en las técnicas antes mencionadas. Son muy escuetos, limitándose a definir el nombre de la actividad, propósito, tiempo esperado, descripción, pasos o tareas a realizar, materiales requeridos y algún ejemplo. Este ejemplo es la parte de la que más adolece el libro, ya que en algunos casos se despachan el ejemplo en no más de cuatro líneas. Esto para equipos recién formados o Scrum Masters novatos puede ser todo un reto, ya que es necesario practicar varias veces para dominar cualquiera de estas técnicas. A continuación menciono, aunque sea a manera de introducción, algunas de éstas:

• ESVP (Explorer, Shopper, Vacationer, Prisoner). Esta técnica se usa al sentar las bases de la reunión, con el fin de conocer la actitud de los involucrados y tomar las medidas necesarias. De manera anónima, cada quien define cuál es su punto de vista de la reunión: los exploradores buscan descubrir nuevas ideas, con el fin de aprender un poco más acerca del proyecto. Los compradores sólo echarán un vistazo a las ideas presentadas en la reunión, para llevarse alguna idea que les sea útil. Los vacacionistas no están interesados en la retrospectiva, pero toman este tiempo como un descanso ante las agobiantes tareas del día a día. Finalmente, los prisioneros son aquellos que sienten que han sido forzados a tomar esta reunión y preferirían estar haciendo otra cosa.

• Timeline + color dots. Usada para recopilar información, en ésta dinámica todos ayudan a reconstruir las tareas y eventos sucedidos durante la pasada iteración. Con notas post it de diferentes colores se describen los eventos conforme se fueron dando; los colores pueden usarse para determinar tipos de eventos o temas; por ejemplo notas amarillas equivaldrían a eventos relacionados a la tecnología, notas de color rosa significan situaciones dentro del equipo, notas verdes implican cambios relacionados al cliente u organización. Los puntos de colores se pegan por cada miembro del equipo sobre estas notas y pueden tener su propia definición. Por ejemplo, puntos verdes significan éxito o un punto emocionalmente alto; puntos amarillos indican confusión o preocupación; puntos rojos significan molestia o retos complicados.

Retrospective Timeline

Un ejemplo de línea de tiempo. Las notas verdes indican eventos favorables, mientras las de color naranja muestran situaciones problemáticas; las notas amarillas indican eventos significativos. Los puntos en la sección inferior muestran el humor de cada integrante del equipo durante el periodo dado, en base al cual se puede trazar una media. Como puede verse en la gráfica, el quinto día fue el más difícil de la iteración pues casi todos se sentían mal o estaban molestos. (Fuente: thekua.com@rest)

• Diagrama de causa-efecto. También conocido como diagrama de Ishikawa o diagrama de espina de pescado (fishbone diagram), es una herramienta de análisis que permite identificar las causas de algún problema (fase de introspección). Para los novatos se recomienda dejar cada “espina” como el qué, el donde, el cómo, el por qué y el cuándo; a partir de ahí reconstruir las causas. Para aquellos más versados en esto, es posible identificar la raíz del problema a través de otras definiciones, como:

  1. Métodos, herramientas, insumos, personal.
  2. Lugares, procedimientos, gente, políticas.
  3. Ambiente, proveedores, sistemas, habilidades.

• Priorizar con puntos. Cuando deben decidirse los siguientes pasos a tomar, se puede utilizar esta dinámica para definir sobre qué tareas es necesario enfocarse durante la siguiente iteración. Primero, se genera este listado de tareas y luego se hace entrega a cada miembro del equipo de varias etiquetas o puntos de color que equivalgan a 1/3 o 1/2 el número total de ítems listados. Una vez que todos hayan colocado sus puntos sobre el tema que más les preocupa, es posible encontrar las tres o cuatro tareas a las que estará más comprometido el equipo.

• SMART (Specific, Measurable, Attainable, Relevant, Timely). Esta es otra herramienta que permite definir los objetivos de proceso durante la siguiente iteración. Creada en 1981 por George T. Doran, es la manera en que muchas empresas definen sus objetivos anuales o semestrales. En este caso, serán los objetivos por alcanzar durante la siguiente iteración.

• +/Δ (más/delta). Para cerrar la retrospectiva, se utiliza la siguiente dinámica para descubrir las fortalezas y debilidades del equipo. Se generan dos columnas: (+) que significa las técnicas, tareas o herramientas que funcionaron bien durante la presente iteración y (Δ) que contendrá las áreas de oportunidad que es necesario atacar. Cada participante incluirá al menos una y una; de esta manera los integrantes pueden visualizar que “no todo está mal”, sino que hay áreas donde su desempeño es sobresaliente.

Finalmente, los dos últimos capítulos contienen tips para ejecutar retrospectivas por despliegue (release retrospective) y retrospectivas de proyecto, que se llevan a cabo al final del mismo.

Conclusiones

El libro es una buena guía para equipos poco experimentados que quieran obtener el máximo provecho de las retrospectivas al final de cada iteración, release o proyecto. La lectura en sí me parece bastante árida porque es casi una “guía para educadores” que contiene las técnicas tal cual sin explicar de dónde salieron o cuál es su función al final del día. Es decir, dentro del contexto del Shuhari aquí sólo nos muestran el Shu (apréndete esto sin preguntar). Vamos, algunos sitios en Internet poseen mucho mayor detalle describiendo estas técnicas y cómo pueden ayudarnos en nuestros proyectos ágiles. Sin embargo, si vemos este libro como un compendio o recetario para después buscar cómo refinar o combinar sus técnicas por nuestra cuenta, me parece una buena referencia que es necesario leer si uno quiere desempeñar el rol de Scrum Master o gerente ágil.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: