Existen muchas dudas en la compatibilidad de Scrum con los equipos que quieren hacer Continuous Delivery. El Continuous Delivery es una tendencia que nació gracias a Agile y que propone que un equipo entregue de manera continuada, para generar valor a los clientes o usuarios constantemente. Sin embargo, Scrum tiene la particularidad de funcionar en iteraciones llamadas Sprints que dificultan esta entrega al realizarse tras varias semanas ¿Cómo podemos hacer compatible Scrum y Continuos Delivery?
La entrega continua, un nuevo paradigma
Agile incorpora entre sus principios que un equipo debe ser capaz de entregar en periodos entre dos semanas y dos meses. En el año 2001, esto era todo un reto ya que se tendía a proyectos donde las entregas se realizaban cada muchos meses o incluso años. La estrategia que se seguía estaba muy influenciada por el mundo de la arquitectura o la ingeniería, donde solemos esperar a tenerlo todo listo para que nuestro producto se pueda utilizar.
Esta filosofía genera muchos errores en el desarrollo del software porque tardamos demasiado en entregar y, por tanto, en evaluar si vamos por buen camino. Agile propone hacer entregas de dos semanas o dos meses para acelerar nuestra capacidad de aprendizaje y adaptarnos al mercado.
Sin embargo, en estos veinte años de Agile, la digitalización ha revolucionado el mundo. Esta revolución ha supuesto que estrategias de entrega continua ganen enteros para poder estar continuamente dando valor en un mundo tan cambiante. No todos los productos que se realizan utilizan esta estrategia de entrega continua, pero sí es verdad que en muchos de ellos tendría sentido hacerlo.
Scrum es iterativo
Scrum se define como un marco de trabajo iterativo e incremental. Por un lado, Scrum propone que vayamos incrementando nuestro producto a medida que vamos entregando, de manera que, el valor se maximice. Por otro lado, Scrum funciona a base de iteraciones llamadas sprints que suceden una detrás de otra.
Un Sprint es un periodo de tiempo inferior a 30 días en el que debemos realizar incrementos y sobre el que inspeccionamos y adaptamos. Esto nos garantiza que, al menos una vez cada 30 días, analizamos diferentes aspectos clave de un equipo como son los resultados que estamos consiguiendo o nuestro proceso de trabajo.
En cada iteración, nos adaptamos con pequeños cambios que nos habiliten para entregar mayor valor. Esta es la clave cuando nos enfrentamos a problemas complejos: ejecutar, inspeccionar y adaptarnos.
Debemos entregar cada Sprint
El concepto de incremento se ha redefinido en la última versión de Scrum para clarificarlo. Cada vez que completamos un trozo de nuestro producto que sea útil para el customer final, podremos incrementar nuestro producto, es decir, puede haber varios incrementos durante un Sprint. Hay equipos que incrementan, pero no entregan el producto por la estrategia que ha marcado el Product Owner.
Recordemos que un equipo debe definir su estrategia de entrega o, por decirlo de otra manera, según el problema complejo que esté tratando de resolver o su modelo de negocio. A veces, interesa entregas continuas y otras, períodos de tiempo más largos.
Por tanto, aunque debemos entregar incremento en cada Sprint, la cantidad y la frecuencia dependerá de la estrategia que sigamos para maximizar valor en el contexto en el que nos encontremos. Aun así, las personas que ejercemos de Scrum Master solemos recomendar que la frecuencia de entrega sea la máxima posible. Cada vez que entregamos, conseguimos aprender de nuestros customers.
¿Cómo podemos compatibilizar continuous delivery con Scrum?
Existe un debate sobre cómo unir Continuous Delivery y Scrum. Puedes tener una estrategia de entrega continua en la que, cada vez que incrementas, una parte de tu producto automáticamente la llevas a producción. De hecho, hay equipos que son capaces de hacerlo varias veces al día.
Esta estrategia es compatible con Scrum, porque Scrum no obliga a esperar al final del Sprint para realizar una entrega. Un Sprint no es un periodo de tiempo donde entregas al final, sino un periodo de tiempo donde se inspeccionan y se adaptan diferentes aspectos del producto independientemente de la estrategia de entrega de que dispongamos.
Es más, si tenemos una estrategia de entrega continua, el Sprint será mucho más rico porque podremos inspeccionar los resultados reales que estamos dando, antes que con nuestras entregas al finalizar el Sprint. Los equipos que no apuestan por Continuous Delivery sólo inspeccionan lo que han terminado, sin haberlo validado con los clientes en un entorno real.
Conclusiones
Scrum es un marco que nos fuerza a que inspeccionemos y adaptemos diferentes aspectos de nuestro producto para conseguir maximizar valor. La inspección y la adaptación deben ser continuas (mínimo cada 30 días) porque nos enfrentamos a problemas complejos que requieren de adaptación continua, ¡no se pueden planificar!
Pensamos que una de las grandes ventajas de Scrum es que a los equipos les pide que sean responsables con los resultados de su trabajo y sepan adaptarse continuamente en base a ellos. Para que ocurra, el equipo debe tener libertad en cómo trabajar. A muchos equipos tener una estrategia de entrega continua les ayuda a que ese valor sea mayor y, por tanto, Scrum es compatible al cien por cien.
Y tú, ¿utilizas Continuos Delivery con Scrum?
