Lo primero que tendremos que hacer es verificar si esas interrupciones urgentes son en realidad tan urgentes como nos las pintan o nos hemos dejado llevar por el alarmismo de haber encontrado un error en producción.

Lo segundo que debemos hacer es ver cuál es la razón principal por la que tenemos tantas interrupciones y de forma tan constante ¿Se deben a la mala calidad del software? ¿Quizás debido a las constantes interrupciones? Quizás debamos dedicar algunos sprints a resolver la deuda técnica que hemos ido dejando atrás o a dar más estabilidad a las partes del software que más problemas están dando.

También hay otras cosas que podemos hacer:

Con esta solución mantendremos las tareas ya programadas en la planificación del Sprint. Al tener sprints de una o dos semanas de duración podremos incluir la tarea no planificada como prioritaria en la lista de cosas a hacer en el siguiente Sprint. Si el Sprint tiene una semana de duración tardaremos una media aproximada tres días laborales en comenzar a acometer la tarea urgente.

Esto funcionaría en un mundo ideal pero no todas las tareas pueden esperar varios días para ser solucionadas. El servicio entero podría depender de ella.

Factor de dedicación bajo

Si sabemos que con frecuencia nos llegarán tareas inesperadas que debemos resolver con mucha rapidez podemos bajar el factor de dedicación durante el Sprint para dar ‘hueco’ a la resolución de estos problemas.

Sabiendo que en cada Sprint el equipo tiene capacidad para resolver 10 puntos de historias programadas podríamos comprometernos a entregar solo 7 para que el equipo tenga tiempo de resolver las incidencias urgentes. De este modo no fallaremos un Sprint tras otro en entregar lo prometido.

En mi opinión esta solución puede ser útil en ciertos proyectos pero puede crear otro problema. Me explico: Habitualmente el factor de dedicación es del 75%, si lo bajamos para poder dedicar un 30% del tiempo del equipo a las tareas urgentes deberíamos aplicar un factor de dedicación del 40-50%. Sobre este 40% aplicamos Scrum pero ¿Cómo se está gestionando el resto del tiempo del equipo? ¿Qué sabemos sobre esa pila de tareas que estamos resolviendo Sprint tras Sprint?

Evitemos crear equipos sólo para dar soporte

Eso sería un anti-patrón a evitar en todo tipo de proyectos. Si creamos equipos que se dedican sólo a resolver bugs o errores encontrados en producción dejaremos al resto de equipos con las manos libres para centrarse en su trabajo sin interrupciones para llegar al final del Sprint pero esto puede hacer que cada vez aumente más el número de errores encontrados.

Los equipos necesitan hacerse responsables del trabajo que entregan y si no ven lo que se causa entregando código defectuoso porque otro equipo especializado se encarga de ello, estaremos fomentando que aparezcan más y más errores. Si ellos mismos tienen que corregir sus propios errores, terminarán dándose cuenta de lo importante que es la calidad para evitar desaguisados y de lo que tienen que hacer para construir software más robusto que evite tanto error.