En Scrum todo gira alrededor del Sprint: la velocidad del Sprint, las USs del Sprint, las sesiones del Sprint… Y lo ideal es que al finalizar el Sprint publiques todos los desarrollos que has finalizado en ese Sprint. Muy bonito… pero si en vuestro caso:
- los desarrollos son complejos y se tardan varios sprints en obtener el desarrollo listo para subir a producción
- las Releases tienen una periodicidad más larga que la de los Sprints
Tenéis una situación Sprint VS Release donde tanto sprint despista y dejamos de ver la Release*. Y la Release señores es lo más importante. ¿Para quién? Para los que más importan… los clientes. Es el momento en el que vas a entregar a los clientes la nueva funcionalidad. ¿A quién le importan los Sprints? Sólo a nosotros. Los sprints son espacios temporales que ayudan al equipo a estar enfocados y sin interrupciones, nada más. Lo importante es la Release. Y mientras no se llega a la situación ideal de subir código al finalizar el Sprint creo que se necesita una sesión para dar foco a este momento tan importante, la publicación de los cambios. Así que me he inventado la “Sesión de versión”.
El objetivo de la «Sesión de versión» es repasar entre todos (equipo y stakeholders) los desarrollos susceptibles de incluir en una Release.
La “Sesión de versión” se realiza días antes de congelar** la versión y en ella se revisan todos los desarrollos cuya publicación objetiva es esa versión. Y me diréis: «La fecha de Release se va actualizando en las distintas sesiones del Sprint, no veemos la necesidad de dedicar una sesión a esta revisión». Os explico mis motivos:
- Los Sprints están diseñados para dar la máxima velocidad al equipo. En una empresa un equipo puede necesitar Sprints de 2 semanas, otros de 3, otros de 1,… Cada equipo experimenta y decide cómo le va mejor trabajar. Esta es la gracia de Agile.
- Las Releases también tienen su propio ciclo de vida y es más, nos podemos encontrar en que cada canal (web, app, otros) tenga ciclos de vida independientes. Este ciclo de vida está muy pensado e intenta encontrar el punto de equilibrio entre: calidad, coste y tiempo.
Y pensareis, ¿aquí cada uno va a su rollo o qué? Pues si. Creo que lo bueno es que cada uno vaya a su ritmo, a su ritmo más eficiente. Y como cada uno da sus vueltas a su ritmo, los equipos por un lado y las releases por otro, necesitamos un momento de pausa. Los equipos necesitan un momento en el que mirar a la Release y decir: «Esta a punto de llegar el tren Realease, ¿qué proyectos subimos?». Pensad que este momento a un equipo le puede pillar a mitad de Sprint de 3 semanas así que puede pasar de la Release objetivo se puede haber cumplido o no.
Pongamos un ejemplo.
| En la empresa A tenemos 4 equipos agile y 2 canales, web y app. Los ciclos de estos son los siguientes: · Equipo 1: Sprints de 3 semanas · Equipo 2: Sprints de 1 semana · Equipo 3: Sprints de 2 semanas · Equipo 4: Sprints de 2 semanas · Canal web: Release cada 4 semanas · Canal app: Release cada 2 semanas · Tiempo de congelación web/app: 1 semana Con esta situación la «Sesión de versión» la situaría 10 días antes de cada Release. |
Una vez explicado el porqué de la sesión os explico de que va. Como os he dicho el objetivo es evaluar por parte de todo el equipo y Stakeholders los desarrollos que queriamos subir en la próxima Release. Aquí tendremos desarrollos listos para subir, otros imposible que suban y algunos que están casi listos para publicar. ¿Por qué? A ver, los que están listos no tienen problema, simplemente se confirma con todos los participantes que están de acuerdo en su publicación, a veces pueden surgir motivos ajenos al equipo que «pausen» su publicación. A los desarrollos que seguro no vamos a poder terminar para subir se les actualiza la Release objetivo y nos aseguramos de que todos los participantes les ha quedado claro que no subirá en esa Release, esto puede suponer retrasar campañas de comunicación y demás, es importante que el mensaje llegue a todos. Pero los desarrollos que más nos interesan son los casi listos. Los casi listos son los que con un poco de empuje se pueden llegar a terminar antes de la congelación. Puede que al PO le interese ajustar la priorización de los temas con la foto actual y con la Release tan cerca.
*La Release es el momento en el que pones a disposición del cliente los nuevos desarrollos. En web ese momento se produce cuando pones el nuevo código en los servidores web públicos y en APP es cuando pones disponible para descargar por parte del cliente la nueva versión de tu aplicación.
** La congelación de versión es un espacio de tiempo en el que se validan todos los cambios que se van a publicar de forma integrada