Scrum se basa en la ejecución de pequeñas iteraciones de varias semanas denominadas Sprints donde el equipo va desarrollando los requisitos seleccionados al comienzo de cada una de esas iteraciones (en la reunión de planificación del Sprint). El cliente puede tener entregas del proyecto que incluyan los resultados de varios Sprints y, una vez finalizados, todos los ellos hemos terminado el proyecto.
Una de las partes más críticas en Scrum es el fin de Sprint. Una vez terminada 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 demostración de final de Sprint es que, al menos en nuestro caso, el desarrollo se para completamente. Una semana completa antes del final la gente pasa a centrarse en sacar la demostración adelante, y durante este tiempo se descubren muchas cosas. Esto abre la cuestión sobre si es realmente valioso el parar el desarrollo 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 tras la demostración habrá que arreglar correctamente. Mi opinión es que es tremendamente valioso, básicamente por todo lo que pasa en ese proceso de preparación de la demostración:
- Se realiza un esfuerzo por integrar los requisitos desarrollados durante las últimas semanas para obtener un resultado compacto y demostrable al cliente final, lo cual revela numerosos problemas imprevistos y de calidad. Lo más importante aquí es que estos problemas se detectan por adelantado en las primeras iteraciones de desarrollo (Sprints), mientras que en un proyecto tradicional en cascada estos errores se detectarían al final y serían mucho más complejos de resolver.
Una persona tiende a responsabilizarse sólo de la parte de trabajo que realiza, es más difícil sentir la propiedad del resultado de un requisito cuando el equipo es multidisciplinar y se necesitan varios especialistas para completar este requisito. A menudo diferentes equipos trabajan en diferentes aspectos/componentes del producto o ámbitos del proyecto, funcionando como islas independientes unos equipos respecto de los otros. Descuidar la interacción entre estos distintos aspectos o componentes puede traer problemas a largo plazo. Por ello las demostraciones 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 demostración, 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 demostraciones obligan al pragmatismo y a la creación de un producto susceptible de ser entregado al cliente con el mínimo esfuerzo necesario. Otro aspecto que yo considero importante de las demostraciones es que los miembros del equipo 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 miembro del equipo se debe centrar en desarrollar un requisito de manera pragmática y siempre pensando en tener algo que entregar, algo que se pueda demostrar.
Esto abre otro debate sobre como poner en un Sprint requisitos no tan fácilmente demostrables como puedan ser cambios internos del producto que no aportan valor directo al cliente o usuario, pero que facilitan añadir nuevos requisitos o cambiarlos, hacen el producto más adaptable o, simplemente, permiten mejoran su calidad. Pero eso ya es un tema diferente.
- Involucración por parte de los miembros del equipo. Personalmente creo que la demostración no debe ser realizada por única persona, sino que aquí el Facilitador (Scrum Master) debe actuar como simple maestro de ceremonias. Hacer que los miembros del equipo participen en la demostración 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 demostración para toda la compañía. Vosotros ya sabéis como es el trabajo en una compañía medianamente grande. A menudo la mayoría de departamentos o equipos trabajan de manera independiente, y prácticamente el único contacto que tienen con el proyecto es para conocer los problemas que unos tienen con el trabajo de los otros. "¿Oye, cómo teníamos que integrar vuestra parte de producto con la nuestra?", "¡Este requisito no se ha hecho como esperábamos, estamos perdidos.", "Hay que hacer cambios corriendo, ahora mismo os hacemos una petición formal de cambios", etc.
Me atrevería a decir que es común que la sensación de las personas ajenas a un equipo, poco antes de terminar cada iteración es más pesimista que cuando el Sprint había comenzado, ya que el único input que han tenido es que ha habido problemas. Sin embargo, el hacer una demostración con los objetivos cumplidos que fueron marcados al inicio de Sprint, 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 del Sprint.
- Visibilidad para el cliente. Teóricamente las demostraciones 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 demostraciones internas se trasladan a otro equipo que se encargará de repetirla con el cliente final, ya en sus oficinas. Con la demostración el cliente puede comprobar que se está progresando, lo cual en el mundo de los proyectos 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 demostración, al menos en nuestro caso.
Proyectos Ágiles 