Resolviendo Incidencias: Buffer de Interrupciones

Incidencias. Si hay algo que la gestión de proyectos y el trabajo a demanda nos ha dejado más que claro es que si algo puede fallar, lo más seguro es que falle. Ya sea una línea de código, unas variables superpuestas que nunca conversaron entre sí, o la misma coordinación entre dos o más equipos supuestamente de “elite”.

Pero a lo hecho, pecho. Somos profesionales, así que no queda otra que arreglar el problema sobre la marcha y seguir resolviendo lo urgente como si la carga extra no hubiese sido la gran cosa, aunque eso significase perderse una que otra pausa activa, un almuerzo o el cumpleaños de un sobrino.

¿Pero qué pasa cuando esta excepción es la realidad? ¿Cuando constantemente ocurre un cambio de prioridades y no se nos permite culpar al Product Owner, debido a que directamente impactamos al cliente? Claramente, entregar valor una vez cada 2 a 4 semanas no nos permite generar el tiempo de reacción suficiente como para responder a emergencias.

Y aunque podríamos terminar el artículo simplemente con un “Cámbiate a Kanban”, la verdad es que sería irresponsable de nuestra parte tanto sugerir una solución sin haber profundizado en el dolor, como escribir un artículo de sólo cinco párrafos.

Por eso, si los incidentes han sido un problema para tu desarrollo iterativo incremental, pero a pesar de eso debes seguir generando incrementos de forma iterativa, hoy te traemos la solución: El BUFFER DE INTERRUPCIONES (Música dramática). Y sí, quizás el nombre resulte un poco aparatoso y técnico para simplemente tratarse de reservar un poco de capacidad durante el Sprint por si pasa cualquier cosa. Pero ya sabes como es esto, si no vende, no se aplica.

El Buffer de interrupciones consiste en dejar una porción de la capacidad del equipo para resolver improvistos basándonos en la data histórica de los últimos Sprints (Si no la tienes, experimenta, recuerda que acá trabajamos de forma empírica). De esta manera sacrificamos parte de nuestra velocidad estimada para generar una capacidad de reacción que nos permita resolver los incidentes urgentes.

¿Están saliendo múltiples solicitudes imprevistas debido a lo errática que está la competencia? Buffer de interrupciones. ¿Tuvimos un paso a producción que terminó por generar más bugs que comentarios positivos? Buffer de interrupciones. ¿El objetivo de producto se está viendo amenazado debido a solicitudes fuera de lugar que…. Ya captas la idea.

En general, recomendamos que antes de comenzar a aplicar esta división de carga, entendamos bien la cantidad de esfuerzo y de interrupciones que solemos recibir, para tratar de darle predictibilidad al marco de trabajo, y no simplemente reservar por reservar durante meses. La Planificación del Sprint puede ser una buena instancia para discutir sobre cuánta capacidad debería ser necesaria, aunque por lo general el porcentaje no suele ser superior al 25% de la capacidad del equipo, aunque esto puede variar según la realidad del negocio y la naturaleza del producto.

¿Y cómo lo llenamos? Simplemente hacemos estimaciones exprés cuando ingrese un nuevo problema y lo hacemos calzar con la capacidad reservada, aprovechando el ciclo de inspección que nos proporciona Scrum para evaluar iterativamente cómo nos hemos enfrentado a las incidencias. Eso sí, hay que poner atención a las interrupciones enormes, y a la cadencia que estas puedan tener, añadiendo al Buffer sólo aquellos puntos que sean de suma prioridad, no vaya a ser que terminemos perdiendo por completo el foco incremental e iterativo del marco de trabajo para dedicarnos exclusivamente a resolver tickets a demanda (En ese caso, sí que recomendaríamos Kanban).

Ten presente que para que esto pueda funcionar correctamente es necesario apuntar a ciertos estándares que, dependiendo de tu realidad, podrían variar. Pero en lo general recomendamos:

• Si tu equipo funciona con estimaciones, estima también los incidentes que ingresen a tu Buffer de interrupciones. Serán excepciones de negocio, pero no metodológicas.

• Si haces reportes de velocidad, no consideres el peso de los incidentes como parte de la métrica, ya que estos variarán con el tiempo y le restarán predictibilidad al marco de trabajo.

• Si llegas a sobrepasar la capacidad del Buffer de interrupciones, evalúa con tu equipo y con tu Product Owner si es necesario cancelar el Sprint y realizar una nueva planificación para centrar a todo el equipo en resolver los problemas urgentes. A veces es necesario despejar el camino antes de seguir construyendo.

• Recuerda que cada parámetro que uses para medir este método, debe estar basado en tu propio proceso empírico y en la información que provea el equipo.

Esperamos que este enfoque te ayude a resolver tus crisis con Scrum. (Ya sabes, esa parte donde el marco de trabajo no llega). A nosotros, en lo personal, nos ha servido de maravilla a la hora de enfrentarnos al soporte que entregamos posterior a una entrega en producción. Dándonos como resultado una mejor respuesta a incidentes, bugs o interrupciones, equilibrando la flexibilidad y capacidad de respuesta necesaria para el día a día, con el empirismo y la predictibilidad que busca generar SCRUM sobre la incertidumbre

Como siempre, esperamos que este artículo te entregue valor, y que ante cualquier duda que tengas, nos contactes para charlar un rato o ver cómo te podemos ayudar. Hasta la próxima!!