¿Cuánta importancia hay en la finalización y cierre exitoso de los sprints?

Burn-down de un sprint exitoso

Cuando acompañas a equipos de desarrollo como coach ágil no tienes relación directa con los proyectos, por tanto no te afectan los problemas del mismo, pero si te llevas las emociones de las personas con las que al fin y al cabo tratas día a día. Este post nace de mis experiencias con un equipo que trabaja con Scrum pero que tiene que ajustarse a unos hitos pensados a modo de cascada al principio del proyecto, ideados en el momento de mayor ignorancia y por tanto cada vez más lejanos a la realidad. El resultado es que una y otra vez incluyen historias de usuario en la pila de sprint por encima de su capacidad, lo que resulta en que una y otra vez entregan incrementos incompletos.

Recordemos lo que es la reunión de revisión de sprint: se trata de una reunión informal realizada al final de cada sprint para comprobar el incremento que debería de estar finalizado (terminado, probado, operando en el entorno del cliente, hecha la documentación de usuario, documentación técnica, etc.,). Debe de asistir todo el equipo de desarrollo, el Propietario del Producto, el Scrum Master y todos los interesados receptores del producto. Los demás interesados que lo deseen también están invitados.

El Propietario del Producto repasada las definición de hecho (DOD) e identifica las funcionalidades que se pueden considerar “hechas” y las que no. Al mostrar el incremento a los interesados objetivo, el Propietario del Producto y el equipo obtienen feedback relevante para revisar la pila del producto, así como información para mejorar la visión del producto.

Scrum realmente es una gestión de entregas con la que obtenemos con cada sprint un incremento potencialmente instalable en producción, un incremento finalizado que fue guiado por los criterios de aceptación y que debe de cumplir con la definición de hecho, y eso cada pocas semanas. Eso implica que el estrés de las entregas se trae a principios de proyecto. De repente equipos que no han rodado en Scrum se encuentran con que, en vez de una fecha de entrega a largo plazo o fechas de hitos a medio plazo, tienen una fecha de entrega cada pocas semanas ¡y esa fecha es inamovible! En los proyectos con metodología tradicional todo el equipo sabe que, aunque haya fechas aparentemente inamovibles, cuando esta se acerca y no es posible realizar una entrega en condiciones, esta fecha se retrasará, o sino se entrará en una segunda fase o se hará lo necesario para tratar la desviación. Pero en Scrum no es así, el sprint tiene una cadencia de duración fija.

Veamos el síndrome del estudiante, este es un fenómeno que forma parte de la naturaleza humana por el cual las personas nos espabilamos y comenzamos a dedicarnos seriamente a una tarea cuando la fecha de entrega se acerca, y eso lo sentimos en forma de estrés. Incorporar la naturaleza humana, y no ir en contra, es una de las fortalezas de Scrum. Con los sprints con fecha de entrega cada pocas semanas se focaliza a las personas en las tareas a realizar, en entregas muy cortas que son factibles sin esfuerzos, generando así el beneficio de un tono de ritmo de trabajo sostenido.

Sonrisa para el final de semana a final
de sprint - Cortesía de Pixabay

Los problemas de motivación y compromiso aparecen cuando no se resuelve ese estrés con cada revisión de sprint, y si de forma repetida el equipo no finaliza los sprints este se suma de un sprint a otro. Scrum al poner de manifiesto todos los problemas desde el primer momento, cosas que no suelen ser otra otra cosa que problemas sistémicos, acabará por escalar el estrés a todos los niveles en forma de bola de nieve.

Mi consejo a los equipos de desarrollo en esta clara situación de ScrumBut es que no piensen en las fechas del proyecto, que se focalicen en realizar y entregar sprints bien hechos. Si de forma continuada entregan incrementos bien hechos habrán ganado la confianza del cliente y la percepción será la de un equipo que funciona, y cuando llegue el momento de alguna fecha incumplida la actitud será muy distinta.

Para los que seáis Scrum Masters animaros a que deis máxima prioridad a que los equipos finalicen los sprints, que haya criterios de aceptación escritos en la planificación de sprint y que se revisen en la revisión de sprint, y en caso de haberse cumplido por encima de un 90% haya reconocimiento explícito por parte del Propietario del Producto, por ejemplo "¡Chicos, buen trabajo!". El viernes de la revisión de sprint el equipo ha de irse de fin de semana contento, con sensación de trabajo bien hecho, y el cliente también, con sensación de avance y sintiendo que dirige el rumbo de su producto.