El procedimiento de emergencia

Hay un antiguo patrón en Scrum, cuando hablo de patrón me estoy refiriendo a una buena práctica típica a un problema común (el concepto de patrón de toda la vida), y que, además, esta práctica no está en la guía oficial de Scrum, sino que viene de su comunidad, que es el «procedimiento de emergencia».
Lo he recordado, y de ahí este post, porque hace poco he vuelto a ver los efectos que produce cancelar por completo los objetivos de un Sprint, es decir, una vez comenzado, por razones varias, dejar todo lo que se estaba haciendo para solucionar un problema inesperado, o implementar un conjunto de necesidades que no estaban previstas para ese momento, y no sólo de cuestiones de negocio, también puede venir de inesperados problemas técnicos.
Hablando en grandes áreas, los problemas grandes en un Sprint suelen venir de dos focos:
– Nuevas necesidades, aparecen items urgentes no esperados que tienen que entrar en el Sprint, correctivos urgentes, etc.
– Problemas técnicos, algún tipo de problema inesperado que genera que no se pueda completar gran parte de lo que se había previsto para ese Sprint.
Si llevas algo de tiempo trabajando bajo un modelo Scrum es más que probable que hayas vivido esta situación.
Los efectos anímicos te los puedes imaginar, si es que nos los has vivido, típicamente frustración, bajón de moral, como normalmente los cambios de alcance vienen de un Stakeholder de nivel superior a un Product Owner, sentimiento de orgullo herido en el Product Owner, sentimiento que se traslada al equipo, etc.
Sin que sea la solución a todos los males, el «procedimiento de emergencia» habla de tener previsto, ya desde antes, qué hacer cuándo surgen problemas gordos en medio de un Sprint.

Un «procedimiento de emergencia» son apenas unas cuántas líneas, más que nada a modo de recordatorio, de qué hacer, o qué no olvidar en esas situaciones. Cuando se trabaja bajo situaciones de presión es típico que se olvide tratar algunos aspectos, obrar de cierta manera, etc.
Cosas como, por ejemplo, y opcional, cerrar el Sprint y empezar uno nuevo, o crear un micro Sprint dentro del actual, con qué tipo de ayuda externa se podrá contar en estos casos, tipos y formato de reuniones de crisis, etc., son cosas que suelen reflejarse en un procedimiento de emergencia.
Y hay otro tipo de acciones, que es una de las cosas que quería resaltar en este post, que se suelen pasar por alto, que creo que deberían tener todo buen «procedimiento de emergencia» y que son las relativas a la comunicación y la gestión emocional. Por acciones de comunicación me refiero a dedicar un breve evento a justificar y exponer las razones por las que ha sido realmente necesario cambiar drásticamente el alcance de un Sprint.
La mayoría de las veces estoy seguro de que había razones de peso para imponer ese cambio de alcance drástico (aquí no me estoy refiriendo a introducir pequeños items inesperados), y hubiese ayudado no sólo tener un breve «procedimiento de emergencia», sino también que este procedimiento incluyera el punto de recordar tratar la comunicación, trasladar al equipo las razones que han llevado a ese cambio, lograr esa empatía. No olvides esta parte.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

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.

Últimas entradas de jgarzas (ver todo)

• 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