Empieza la reunión de Sprint Review. El Equipo de Desarrollo y el Product Owner presentan al cliente lo que hicieron en dicho Sprint. El cliente observa, pero habla poco, excepto por unas pocas preguntas básicas. Al final, aprueba (e incluso aplaude) y se despide.
Todos piensan: «¡uf! La reunión ha sido un éxito». ¿Pero lo habrá sido realmente? En realidad, creo que ésta es una de las peores situaciones posibles para una Sprint Review. Peor que eso, quizás, solo si el cliente no estuviese presente.
¿Pero habrá entendido ese cliente lo que se le ha presentado? ¿Le habrá importado lo que estaba viendo? Ciertamente le importará en un futuro, posiblemente cuando utilice el software y note que no responde correctamente a sus necesidades.
El propósito de la reunión de Sprint Review no es obtener la aprobación formal del cliente sobre lo que se ha hecho en el Sprint, es decir, que levante el pulgar, o que ponga un sello de «aceptado» en el contrato. No es UAT (User Acceptance Testing) tampoco. El objetivo de dicha reunión es obtener feedback del cliente sobre el Incremento del Producto generado en el Sprint y, con ello, poder hacer frecuentemente ajustes de dirección y, así, disminuir los riesgos del proyecto. Es trabajo – y obligación – del Equipo de Desarrollo y del Product Owner tirar por el feedback del cliente. Invitarlo a usar el producto allí mismo. Instigar. Hacer preguntas. Mostrar alternativas.
¿Su equipo busca aprobación o feedback al realizar una demo para el cliente?
¿El cliente consideró que algo no estaba exactamente como él quería? Perfecto! Pongamos a un lado la postura defensiva. No tengamos miedo. Nosotros no hemos hecho nada malo. No hemos estropeado todo. En realidad, estábamos esperando esto. Haremos todo lo posible por acertar, claro, pero no sabemos leer la mente de nadie. Y, aunque supiésemos, eso no resolvería mucho, dado que el cliente solo sabrá exactamente lo que necesita cuando tenga algo listo. El producto, en la cabeza del cliente, se construye poco a poco, gradualmente.
Incluso cuando todo salga mal y el cliente entienda que todo lo que se hizo en el Sprint no sirve para nada, al menos obtendremos dicho feedback antes de pasarnos meses trabajando en aquello. Gestión de riesgos pura, ¿no?
Es decir, el espíritu de la Sprint Review no es:
Cliente, ¿está aprobado lo que hemos hecho?
Sino, tal vez algo así:
Sr. Cliente, ahora que tiene la oportunidad de ver funcionando (¡y de probar!) este Incremento del Producto que hicimos para usted en esto Sprint, ¿qué podemos cambiar o añadirle a sus necesidades?
