Ya sabemos tod@s que las interrupciones son desperdicio, producen cambio de contexto, etc. De esto ya hemos hablado en otras ocasiones, te dejé en su día un vídeo, en el canal de YouTube, y hay incluso un post muy antiguo post del 2013.
De ahí viene ese ideal de que, en Scrum, una vez que se comienza un Sprint no se cambie el alcance, no entren imprevistos, etc.
Pero ya sabemos todos que los ideales no se ajustan siempre a la realidad y, en muchas ocasiones, mantener intacto el alcance del Sprint es… imposible. Típicamente llegan bugs, urgencias, etc.
Sabemos que esos cambios de alcance en el Sprint son malos para el cambio de contexto, pero, recordemos, «bienvenido el cambio», a veces esos cambios son claves para el negocio y que, como dice una frase de Poppendieck, escribo de memoria, un cambio a ultima hora es una ventaja competitiva. Todo esto entendiendo que sólo se van a introducir cambios en el Sprint que, realmente, no podían esperar al siguiente Planning.
De esto habla un patrón de Scrum que se llama «Illegitimus Non Interruptus», no sé cómo no había en el blog ningún post sobre este patrón (gracias David López por el recordatorio), ni estaba en el listado ese que hice de prácticas (y que como tenemos curso de Agilidad avanzada en Madrid el 18 de marzo, lo acabo de incorporar al listado de patrones que trato en el curso).
El patrón habla de, asumiendo que las interrupciones son una realidad, hacer explícito un tiempo para interrupciones. Y que si se supera ese tiempo… se cancele el Sprint. Y establece la siguiente recomendación:
- El equipo crea un buffer, deja un hueco explícito en el Sprint Backlog para inesperados en base a datos históricos. El tamaño de ese «hueco» en el Sprint Backlog se calcula en función de históricos, en base a cuántos items inesperados suelen llegar por Sprint.
- Y, ojo, aquí viene lo importante, a ese hueco, dentro del Sprint Backlog, tiene acceso directo el Product Owner (que ya sabemos que «de libro» el Sprint Backlog es sólo del equipo técnico), el coloca ahí lo que considera que es tan urgente como para tener que entrar en un Sprint ya iniciado.
- Si se supera ese buffer se cancela el Sprint.
- El buffer no tiene que llenarse necesariamente en cada Sprint, y en este punto aplica aquel viejo patrón de “equipos que terminan antes aceleran más rápido”, que habla de no cargar al 100% a los equipos, dejando hueco para refactorizaciones, control de deuda técnica, etc.
Ya sabes, experimenta, probar a ver qué tal funciona, inspecciona y adapta. Que la agilidad te acompañe.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
El buffer del lado oscuro! 😉
¡Hola Javier! 🙂
Espero que este nuevo año siga lleno de retos y aprendizajes para ti y todo tu genial equipo.
Este post me ha caído como anillo al dedo, ya que los imprevistos por gestión de la continuidad operativa es el día a día de todos los equipos, especialmente aquellos que trabajan en medio de altos niveles de rotación, como lo es en Venezuela.
Chaito,