¿Cuál es la manera ágil de concebir y acometer las tareas de los sprints?

Patrones de estrategia de sprint

Una de las cosas que aprende un Scrum Master con recorrido es a leer los tableros de los equipos. Un paseo por la sala dónde trabajan estos y con un vistazo a los tableros aprendemos a leer el nivel de autoorganización y multifuncionalidad de los diferentes equipos. 

Los equipos recién aterrizados en Scrum suelen comprender el proceso, las reglas y artefactos de Scrum, suelen no tener interiorizada la mentalidad ágil y tienden a aplicar comportamientos clásicos de pensamiento en cascada a las prácticas de Scrum, convirtiendo estas el algo así como un Frankenstein, hecho a pedazos de ambas metodologías, práctica que recibe el nombre de ScrumFall.

Recién comprendido el marco de Scrum y su construcción incremental e iterativa a base de sprints, los iniciados suelen trasladar las fases de la gestión en cascada a los sprints. Para cada funcionalidad a construir el primer impulso es pensar en modo clásico, en división en horizontal (por capas) y asignar sprints de forma secuencial a las diferentes fases de construcción. En un primer sprint se hace el análisis, que se acaba al 100%, en el siguiente sprint se inicia el desarrollo para finalmente hacer en un último sprint o grupo de sprints el testing (tal como está ilustrado como ScrumFall inter-sprints en la imagen arriba a la izquierda). Posiblemente esta solución sea mejor que un proyecto sin iteraciones, ya que así tenemos muchos pequeños proyectos y minimizamos riesgos y tenemos puntos de feedback, pero estamos lejos aún de ser ágiles y de beneficiarnos de todo lo que aporta Scrum. Este patrón se suele corregir de forma temprana, una buena formación en que se resalte la mentalidad ágil suele evitar que los equipos noveles caigan en esta práctica.

Ejemplo de tablero ScrumFall intra-sprints
 cortesía de Joaquín

Lo que sí es muy frecuente es el ScrumFall intra-sprints. El equipo obtiene la pila de sprint en la planificación de sprint, desglosa en tareas y en ese mismo momento asigna todas las tareas a los diferentes especialistas del equipo. El resultado es una construcción por fases de la funcionalidad, entregamos la funcionalidad completa y finalizada en la revisión de sprint, pero la construcción ha sido en cascada. Construir de esta manera puede funcionar perfectamente, pero perdemos los beneficios del trabajo por parejas o en equipo, los beneficios de las diferentes perspectivas de las personas que lo forman, y de lo que no solemos ser muy conscientes, de que esas fases no siempre son lineales, suele haber retrocesos y bucles que suelen ser un gran desperdicio.

Insistí mucho a uno de los equipos que acompañé como Scrum Master que la maquetadora y el desarrollador del front trabajaran juntos, durante los primeros 5 sprints no lo comprendieron y no lo hicieron, así que las tareas iban y venían de uno a otro hasta que el resultado fuera satisfactorio. Cuando por fin experimentaron mi consejo y se sentaron juntos ante un ordenador lo vivieron de primera mano, el tiempo de construcción se redujo sensiblemente y además se habían divertido y congeniado. Me emocioné mucho cuando expusieron su experiencia en una retrospectiva :-D

Arriba a la derecha muestro un tablero que ilustra ScrumFall intra-sprints en toda su dimensión. Cada uno de los carriles está asignado a uno de los diferentes miembros del equipo y todas las tareas, en diferentes situaciones, están asignadas individualmente a esos miembros. La consecuencia de esa estrategia es que cada miembro está focalizado básicamente en sus propias tareas perdiendo de vista la perspectiva general del sprint. Una segunda lectura que podemos hacer es la de una columna "en construcción" muy saturada, vemos que algunos de los miembros del equipo tienen muchas tareas abiertas, lo que supone convivir con el desperdicio de la multitarea y probablemente tiempos de espera por dependencias de otras tareas de otros miembros. ¿No sería deseable que todo el equipo estuviera focalizado a la vez en lo mismo y se ayudasen unos a otros en todo momento?

La forma ágil de acometer tareas en un sprint es la siguiente:

• Por historias de usuario, recorriéndolas de la más prioritaria a la menos prioritaria, y no trabajar en más de una o dos a la vez.
• Con autogestión: el equipo va autoasignando las tareas en las dailys a medida y en función del avance de sprint, eso coordinará y alineará diariamente al equipo.
• De forma cross funcional: el equipo intenta acometer como verdadero equipo una sola historia de usuario a la vez. Los beneficios son que todos los miembros están focalizados y participan de la historia de usuario en curso, con lo que las buenas ideas surgen de las diferentes perspectivas que tiene cada individuo, y permite que los miembros se ayuden y se apoyen entre sí.

¡Pare de comenzar y empiece a terminar!

Termino el post con un buen tablero scrumboard en el equipo está "quemando" las historias de usuario de arriba a abajo, como una unidad cohesionada.

Ejemplo de un scrumboard con un equipo integrado trabajando de manera cross funcional