Si no demostramos al cliente lo que hemos hecho en el último Sprint ¿Cómo podemos saber si vamos bien o vamos mal? Podemos seguir avanzando sin que nadie vea nuestro trabajo, tomando suposiciones y huyendo hacia adelante pero cuando llegue el momento de la entrega final en el que el cliente vea todo el proyecto podemos estar en un apuro.
Es mejor que cada poco lo vaya viendo, que dé su opinión, que corrija errores o malentendidos y sobre todo que nos diga qué hicimos bien y podemos dejar cerrado ya para seguir avanzando. Es necesario estar seguros de que el cliente ha aceptado lo que ha visto y que avanzamos sobre estructuras sólidas sobre las que seguir construyendo nuevas funcionalidades.
La demo tiene también el efecto de probar todo en su conjunto para ver que funciona bien. Alguien podría estar trabajando en el backend, otro en el frontend, otro estaría construyendo un servicio web y un cuarto está trabajando en una migración de datos. En la demo vamos a poner cada dos semanas todo esto a trabajar junto. Van a salir las dependencias, los errores por asumir que ciertas interfaces eran de una manera y no de otra y los problemas que se pueden tener al desplegar (redes, certificados de seguridad, diferencias entre los entornos de desarrollo y de demo o pre, etc.).
También es importante que te reúnas con el Equipo de Trabajo después de la reunión de demo para tener una reunión de retrospectiva. Que te cuenten si están bien, si están teniendo problemas o si creen que algo es manifiestamente mejorable. Justo después de la reunión de demo es el momento para confrontarse con la realidad. Se acaba de ver lo que salió bien y lo que salió mal, lo que quedó fuera porque no hubo tiempo y lo que el cliente rechazó porque no se le había entendido bien. Justo ahí todo el mundo tendrá una opinión de lo que es mejorable. Toma buena nota sobre algunos cambios que podrían hacerse, seguramente saldrán buenas ideas de ahí.
