Sobre la Reunión de Revisión (Iteration Review)

Allá por 2015 escribí una serie de artículos sobre esta reunión y este artículo me quedó a medio escribir en la carpeta de borradores. Ayer por la tarde una consulta de una colega me motivó a completar el borrador y publicarlo. Espero resulte útil.

Las reviews de mis proyectos suelen tener 2 partes a las que suelo denominar PPT y Demo.

La parte de Demo es donde se muestra el resultado del trabajo realizado. En términos de Scrum es el incremento de producto, en términos de desarrollo más genérico es el working software. Algunos puntos importantes: esta demostración del software se hace en un ambiente de Test/QA (o como gusten llamarle) es una ambiente con bastante estabilidad y definitivamente no es la máquina de un developer. Incluso en algún caso muy particular he hecho la demo directamente en el ambiente productivo. Como mencioné en un artículo anterior, la Demo no puedo fallar pues no hay razón para que fallé: la estamos corriendo en un ambiente controlado, tenemos tiempo para prepararla y definir exactamente el flujo de acciones. Es cierto, puede haber algún imprevisto como que se caiga la red y por eso es que debemos tener un plan B. Dicho plan B puede ser correr la demo en otro ambiente o bien tener la demo grabada en video. Lo que el equipo considere necesario para asegurar poder mostrar el producto funcionando.

Por otro lado está la parte que suelo denominar PPT en referencia a las diapositivas que se suelen utilizar para guiar esta parte de la reunión. En esta parte de la review repasamos el compromiso, comentamos los eventos relevantes ocurridos durante la iteración y vemos algunas métricas. Finalmente cerramos con una sugerencia sobre los siguientes pasos. En algunos casos, dependiendo de la dinámica del proyecto, puede que también repasemos el estado de los riesgos del proyecto. Todas estas cuestiones se traducen en los siguientes slides:

Portada: nombre del proyecto, número de iteración, fecha
Slide 1: bullets con los hitos relevantes de la iteración y su estado (completo / incompleto)
Slide 2: Burdown chart
Slide 3: Detalle del backlog
Slide 4: Sugerencia de siguientes pasos

Si la iteración incluyó algún entregable que no fuera código (como por ejemplo un spike o algún documento técnico) entonces hay un slide dedicado a esto.

Básicamente considero 3 alternativas para articular estas dos partes:

Primero PPT y luego Demo
Primero Demo y luego PPT
PPT – Demo – PPT

Generalmente utilizo la variante 3.

Dependiendo de la dinámica del proyecto, puede que la demo la ejecute algún developer o directamente el producto owner.

Premisas para reuniones de revisión

Quiero compartir algunos premisas básicas que utilizo intento utilizar en mis reuniones de revisión (iteration review).

Todo el equipo

En la review está presente todo el equipo, ya sea para llevarse halagos o críticas.

Ambiente limpio

La revisión no se realiza en un ambiente desarrollo sino en un ambiente de review/demo, el cual es un ambiente «limpio» y donde el producto queda disponible incluso después de finalizada la reunión para que el responsable de producto y los stakeholders puedan acceder a su gusto en cualquier momento ya sea para realizar demostraciones a terceros, pruebas exploratorias o simplemente para consulta.

La review no se mueve

La reunión de revisión se agenda al comienzo de la iteración y no se posterga por retrasos de parte del equipo de desarrollo. La reunión se realiza y se muestra lo que se tiene, si parte del compromiso no llegó a completarse, no importa, hay que dar la cara y decir que no se llegó. La reunión puede moverse si el responsable de producto o los stakeholders tienen un imprevisto, pero NO puede moverse por funcionalidades incompletas.

Dos tipos de Review

Continuando con la cuestión de la reunión de revisión, ayer hablaba con Charly Paez sobre dos tipos bastante distintos de reuniones de revisión las cuales a mi entender son consecuencia del nivel de participación del responsable de producto a lo largo de la iteración.

Caso de poca participación

En estos casos el contacto entre el equipo de desarrollo y el responsable de producto ocurre en (unos pocos) momentos muy puntuales a lo largo de la iteración: la reunión de planificación, algún mail de validación, alguna reunión de refinamiento y la reunión de revisión. El equipo de desarrollo trabaja en las funcionalidades y consulta al responsable de producto pero recién presenta la funcionalidades terminadas en la reunión de revisión. Esto hace que la reunión de revisión sea una presentación del equipo de desarrollo hacia el responsable de producto. A veces esta reunión de revisión trae sorpresas y se extiende más de una hora.

Caso de mucha participación

En estos casos la interacción entre el responsable de producto y el equipo de desarrollo es mucho más frecuente y fluida. Al mismo tiempo el equipo desarrollo no espera al final de la iteración para mostrar/validar las funcionalidades desarrolladas. Sino que a medida que las funcionalidades van siendo desarrolladas/completadas el equipo las va validando con el responsable de producto. Más aún, el responsable de producto tiene una participación muy activa en las pruebas de aceptación. Esto que hace que el responsable de producto llegue a la reunión de revisión sabiendo de antemano con qué se va a encontrar y habiendo ya usado las funcionalidad que se va a presentar. En estos casos la reunión de revisión tiene un sentido distinto. Ya no tenemos al equipo presentando el producto al responsable de producto (pues este ya lo vio) sino que tenemos al responsable de producto presentando el producto al resto de los stakeholders.

Personalmente cuando puedo elegir, elijo sin dudas este segundo tipo de revisiones ya que cuando pude utilizarlo el resultado de nuestro trabajo tuvo muchísimo más impacto en la organización. En realidad no creo que el impacto sea consecuencia del tipo de revisión sino al contrario: el proyecto era de alto impacto, eso hizo que el responsable de producto tuviera un gran involucramiento en el proyecto y eso derivó una excelente interacción con el equipo de desarrollo y en reviews del segundo tipo.

Continuará…

(no me gustan los nombres que le puse a cada tipo de review, si alguien mejores propuestas, son bienvenidas)

La reunión olvidada: Iteration Review

En el desarrollo (ágil) de software actual hay 3 reuniones bien establecidas: iteration planning, iteration review y retrospectiva. (nota: si bien esta es la terminología propuesta por Scrum no estoy hablando particularmente de Scrum sino de desarrollo ágil en general)

Hay libros enteros dedicados a planning y también los hay dedicados a retrospectivas, pero no ocurre lo mismo con reviews. Al mismo tiempo he visto consultores/facilitadores colaborando en reuniones de planning y retrospectiva (retrospectivas sobre todo) pero no ocurre lo mismo con las reviews.

Curioso ¿no?. ¿Simple casualidad? Mmm, no creo.¿Será que la review es menos importante? No ¿será que la review es más fácil? Mmmmm, no creo. @egutter me dice que es porque la review es anterior al desarrollo ágil y al mismo tiempo la agilidad no ha introducido grandes cambios en esta reunión, como si lo ha hecho en la planning. Esta justificación me resulta bastante convincente.

Mientras escribo estas líneas caigo en la cuenta que en mi propio libro hay capítulos dedicados a planning y retrospectivas pero no dedicado a reviews, ¡Ja!

Personalmente la mayoría de las veces que he asistido a reviews ajenas (o sea de proyectos/equipos en los que no estaba involucrado) me fui decepcionado. Reuniones empezando tarde, demostraciones inentendibles (o directamente fallidas), usuarios/stakeholders ausentes, incluso miembros del equipo ausentes, pérdida del foco de la reunión, horario de finalización incierto, entre otras cuestiones.

Para mi la review es una reunión clave. O tal vez LA REUNION CLAVE. En la planning el equipo asume un compromiso pero es en la review donde se ve el resultado de ese compromiso. Es en la review donde tenemos la posibilidad de deleitar a nuestros stakeholders. Es en la review donde se juega la continuidad del proyecto.

Es por esto que en mi materia de ingeniería de software dedico una clase para que mis alumnos entiendan la importancia de esta reunión y sepan como prepararla y guiarla apropiadamente. Al mismo tiempo como parte de la materia los alumnos tienen que realizar al menos 4 reviews y su desempeño en esas reviews tiene impacto directo en la aprobación de la materia.