Scrum: Me encantan las Sprint demos

La verdad es que cuanto más trabajo con Scrum, más me gustan las Sprint demos. Como la mayoría sabéis, Scrum se basa en la ejecución de pequeñas iteraciones de varias semanas denominadas Sprints donde se va implementando funcionalidad que se ha decidido al comienzo de cada una de esas iteraciones. Durante los diferentes Sprints se pueden ir lanzando releases, y una vez finalizados todos los Sprints hemos terminado el desarrollo.

Una de las partes más críticas en Scrum es el fin de Sprint. Una vez terminado una iteración se suele hacer una demostración del producto. Estas demostraciones teóricamente deberían incluir a los clientes, pero todo depende realmente de cómo y para qué se está utilizando Scrum en la compañía.

Una de las cosas más curiosas de la demo de final de Sprint es que, al menos en nuestro caso, el desarrollo se para completamente. La gente pasa a centrarse durante una semana completa en sacar la demo adelante, y durante este tiempo pasan muchas cosas. Esto abre la cuestión sobre si es realmente valioso el parar a los desarrolladores durante cinco días completos poniendo esfuerzo en preparar algo que puede que en el futuro cambie, o algo para lo que hay que poner un montón de parches que después habrá que recodificar. Mi opinión es que es tremendamente valioso, básicamente por todo lo que pasa en ese proceso de preparación de la demo:

• Se realiza un esfuerzo por integrar toda la funcionalidad creada durante las últimas semanas en un formato compacto y demostrable al cliente final lo cual revela numerosos bugs y problemas imprevistos. Lo más importante aquí es que estos problemas se detectan por adelantado en las primeras fases de desarrollo, mientras que en una metodología de software tradicional estos errores se detectarían al final y serían mucho más complejos de resolver.
  
  Los desarrolladores somos muy vagos en cuanto a end-to-end testing se refiere. A menudo diferentes equipos trabajan en diferentes componentes y funcionan como islas independientes unas de la otras. Descuidar la interación entre componentes puede traer problemas a largo plazo, y las demos ayudan a forzar la integración frecuente de dichos componentes evitando posibles riesgos.
  


• Irremediablemente se crearán soluciones temporales, o hablando más claro: parches. Estos parches estarán ahí en la demo, pero su presencia obliga a preparar y planificar soluciones reales para el siguiente Sprint. El equipo se ve obligado a reservar el tiempo necesario para solucionar estos problemas, y eso ayuda a no encontrarse sorpresas no planificadas de última hora y el tener que hacer esos sobreesfuerzos de los que siempre nos estamos quejando.


• Las demos obligan al pragmatismo y a la creación de artefactos distribuibles. Otro aspecto que yo considero importante es que los desarrolladores no pueden ser "mega-creativos" y crear soluciones que les lleve meses ver la luz (caso aún posible, pero que de darse estaríamos ante proyectos en si mismos y requerirían Sprints propios). El desarrollador se debe centrar en implementar funcionalidad de manera pragmática y siempre pensando en tener algo que entregar, algo que distribuir, algo que se pueda demostrar.
  
  Esto abre otro debate sobre como integrar en un Sprint funcionalidades no tan fácilmente demostrables como puedan ser cambios internos en la arquitectura, refactorizaciones, etc. Pero eso ya es un tema diferente.
  
  
• Involucración por parte de los desarrolladores. Personalmente creo que la demo no debe ser realizada por única persona, sino que aquí el Scrum Master debe actuar como simple maestro de ceremonias. Obligar a los desarrolladores a participar en la demo les obliga a involucrarse más en la misma. El esfuerzo inevitablemente será mayor ya que no es lo mismo poner tú mismo la cara que el que la tenga que poner otro por ti.


• El efecto moral de ver que el proyecto avanza. En nuestro caso por ejemplo hacemos la demo para toda la compañía. Vosotros ya sabéis como es el desarrollo de software. A menudo la mayoría de equipos trabajan de manera independiente, y prácticamente sólo tienen contacto para conocer los problemas que unos tienen con el trabajo del otro. "¿Oye, qué tenía que pasar en este escenario?", "¡Este caso de uso está mal, estamos perdidos.", "¡Change Request", ...
  
  Me atrevería a decir que es común que la sensación cross-team de las personas ajenas al desarrollo de una aplicación al terminar cada iteración sea más pesimista que cuando el Sprint había comenzado, ya que el único input que han tenido estos equpos han sido problemas. El presentar una demo y mostrar que los objetivos marcados a principio de Sprint se han cumplido, y que no todo está tan mal como la gente se piensa, es una fenomenal forma de mostrar que el trabajo se ha realizado, que todo va bien, y de ayudar a recuperar esa moral que se pueda haber perdido durante el esfuerzo de desarrollo.



• Visibilidad para el cliente. Teóricamente las demos deberían incluir al cliente. En muchos casos esto no es posible físicamente, pero lo ideal es hacerlo. En nuestro caso por ejemplo, las demos internas se trasladan a otro equipo que se encargará de repetirla con el cliente final, ya en sus oficinas. Con la demo el cliente puede comprobar que se está progresando, lo cual en el mundo del software no es tan común, además de poder validar todos sus requisitos y sugerir cambios cuando sea necesario.

Y esto sería más o menos el resumen de lo que pasa durante esos días que se prepara la demo, al menos en nuestro caso. ¿Cómo son vuestras demos? ¿Las hacéis? ¿Se diferencian mucho sobre esto?