Cuando secuestran el sprint: la historia de un equipo Scrum frente a las interrupciones a mitad de sprint
Un equipo de producto que daba soporte a una plataforma interna repetía la misma queja en sus retrospectivas: cada sprint empezaba limpio y terminaba en caos. Se comprometían con un objetivo del sprint el lunes, y para el miércoles un director reenviaba una solicitud «urgente», una parte interesada dejaba un «favor rápido» en el chat de alguien, y un sprint backlog a medias se dispersaba. Es un escenario anonimizado, pero si haces Scrum en un equipo híbrido dentro de una organización ajetreada, probablemente hayas vivido una versión de esto.
Diagnosticar el problema real
El equipo culpó primero a las interrupciones en sí. Pero la Guía Scrum ya ofrece los mecanismos para gestionar el cambio; el problema era que el equipo había dejado de usarlos. Tres cosas se habían roto en silencio:
El objetivo del sprint era una lista de tickets, no un único objetivo coherente, así que nada parecía protegido cuando llegaba algo nuevo.
Las solicitudes iban directo a los desarrolladores por mensajes privados, saltándose por completo al Product Owner.
No había un entendimiento compartido de que el sprint backlog pertenece a los desarrolladores y de que el alcance se negocia, no se dicta.
Dicho de otro modo, las interrupciones eran un síntoma. La causa era que el equipo había dejado erosionar la responsabilidad del Product Owner sobre el product backlog, sin ninguna forma acordada de decidir qué era realmente urgente.
Lo que el equipo cambió
No inventaron un proceso nuevo. Volvieron a Scrum tal como está escrito y lo aplicaron con disciplina.
Un objetivo del sprint, claramente formulado. El equipo creó cada sprint en torno a un único objetivo que daba coherencia al trabajo. Un objetivo real hace evidente cuándo una solicitud entrante lo amenaza, y le da al equipo las palabras para decirlo.
Encauzar todo a través del Product Owner. Las nuevas solicitudes ya no caían en los chats de los desarrolladores. Iban al Product Owner, responsable de ordenar el product backlog, que decide si algo desplaza el trabajo actual.
Proteger el sprint, negociar el alcance. Según la Guía Scrum, el objetivo del sprint permanece fijo, pero el alcance puede renegociarse entre el Product Owner y los desarrolladores a medida que se aprende. Un elemento realmente urgente solo entraba si salía otro de tamaño equivalente.
Usar el Daily Scrum para adaptarse. En vez de tratar un cambio a mitad de sprint como una emergencia, los desarrolladores usaban el Daily Scrum para replanificar hacia el objetivo cuando la realidad cambiaba.
Cancelar, no corromper. El equipo acordó que si una emergencia genuina dejaba obsoleto el objetivo del sprint, el Product Owner podía cancelar el sprint: un acto raro y deliberado, no el hábito semanal de meter trabajo a escondidas.
El resultado y la lección
En pocos sprints el patrón cambió. El trabajo realmente urgente seguía ocurriendo, pero ahora pasaba por un único punto de decisión y se intercambiaba contra el alcance existente, así que el equipo dejó de terminar sprints con todo a medias. El director que solía reenviar solicitudes «urgentes» aprendió a esperar una conversación rápida y honesta sobre compensaciones en vez de obediencia silenciosa.
La lección más profunda es que las interrupciones a mitad de sprint rara vez son un problema de Scrum: son un problema de derechos de decisión. Scrum te da los eventos y las responsabilidades para gestionar el cambio sin caos. La mayoría de los equipos que se sienten secuestrados simplemente han dejado de usarlos, sobre todo el objetivo del sprint que le da a todos algo que vale la pena proteger.
Si tus sprints se descarrilan una y otra vez y quieres ayuda para restaurar la disciplina que hace que lo ágil de verdad entregue, la asesoría en entrega de programas y proyectos de XNM puede ayudar a tus equipos a proteger su enfoque sin volverse inflexibles.