El Sprint de Ajuste: Salvavidas (de Plomo?)

La Scrum Guide nos dice que al final de cada sprint, el equipo debe entregar un incremental de software "potencialmente presentable". Pero, ¿qué pasa cuando las dependencias del sistema y otras restricciones de deployment hacen que el entregar algo usable (y que no se rompa) sea imposible? Acá es cuando entra a jugar el sprint de ajuste (hardening sprint).

Un sprint de ajuste es un sprint especializado en el que los equipos de scrum trabajan en cosas como: pruebas de integración, ajustes de rendimiento, revisiones de seguridad y localización (asegurarnos que el software funciona en mercados/culturas locales).

Estos sprints no deben, de ninguna forma, ser tratados para agrupar nuevas características, refactorear código descuidado, corregir errores y otras tareas que indican un trabajo deficiente. En especial, tenemos que estar alerta a algunos de estos usos incorrectos comunes:

1- Se nos acabó el tiempo y no probamos completamente esta función, terminemos la prueba durante el sprint de ajuste.

2- La documentación del usuario no se completó para esta función. Terminemos durante el sprint de ajuste.

3- No es necesario contratar soporte de aplicaciones, seguridad informática o infraestructura ahora, los pondremos al día durante el sprint de ajuste.

Estos abusos son la razón por la cual muchos de los gurús del scrum nos dirán que los sprints de ajuste son un "antipatrón" o simplemente son malos. Una búsqueda rápida en Google nos revela discusiones cruzadas y agudas publicaciones que degradan el uso de los sprints de ajuste. Es territorio volátil, te lo estamos advirtiendo :)

Sin embargo, yo no estoy de acuerdo con que los equipos de scrum que usan sprints de ajuste hayan perdido el rumbo.

Es cierto que al usar un sprint de ajuste el equipo de scrum admite que no entregaron software "hecho" durante sus sprints anteriores. Esto es una indicación de que falta su definición de hecho (Definition of Done). Esto podría ser un impedimento para el éxito futuro del equipo.

Pero esto también podría ser una decisión intencional de la organización. Escribir una impecable definición de hecho es costosa. La integración continua, la alta cobertura de pruebas y los equipos fuertes de DevOps toman tiempo para construirse e implementarse. Tiempo y (mucho) dinero. Durante las primeras etapas de una transformación ágil, los sprints de ajuste pueden ser incluso obligatorios debido a que algunas o todas estas prácticas no están en su lugar. Esto está bien, pero tenemos que tener en cuenta estas 3 ideas importantes cuando decidamos usar un sprint de ajuste:

1- Seamos transparentes con el product owner sobre lo que significa Done ("hecho"): Si "hecho" no es cierto hasta después del sprint de ajuste, el product owner tiene derecho a saberlo. Ser abierto acerca de por qué es necesario el sprint de ajuste le permitirá al PO tomar mejores decisiones sobre los lanzamientos y garantizar que sus presupuestos y planificación de productos sean más significativos.

2- No abusemos de la práctica: Un sprint de endurecimiento no es un pase libre para ser flojo. Mantengamos el trabajo dentro del sprint de ajuste al mínimo y estemos constantemente atentos para reducir el trabajo que es necesario completar en los sprints de ajuste.

3- Reduzcamos la dependencia de los sprints de ajuste con el tiempo: Nuestro objetivo debe ser eliminar eventualmente el uso de sprints de ajuste. En algunas organizaciones, esto no será posible debido a varias limitaciones, sin embargo, inspeccionar continuamente el motivo de los sprints y buscar formas de reducir su frecuencia y duración puede ayudar al equipo scrum a obtener un valor entregado más rápido a nuestros clientes.

La idea adicional, para concluir, es asegurarnos de que nuestra decisión de usar un sprint de ajuste sea intencional. Con esto quiero decir que los equipos de scrum debemos tener un plan para realizar sprints de ajuste y un objetivo a largo plazo para eliminarlos en la medida de lo posible. Si se deja esta decisión al azar, muchas de las malas prácticas mencionadas anteriormente pueden ser el estándar en nuestros sprints de ajuste.