2 Técnicas para Tratar las Emergencias en Scrum

Por Gerardo Morales, Registered Scrum Trainer™

¡Que frustrante! De nuevo no logramos cumplir con el compromiso que hicimos al principio del Sprint, pero realmente no es nuestra culpa… Un error hizo que la pasarela de pago dejara de funcionar y tuvimos que arreglarla, de lo contrario dejaríamos de vender como empresa.

 ¿Te pasa este tipo de cosas con frecuencia? A mi también…  

Por diferentes razones, en varios Sprints nos enfrentábamos a imprevistos o ítems no planeados que obligaban a los developers a interrumpir la producción del incremento al cuál nos habíamos comprometido. Obviamente haciendo que nuestra velocidad disminuya o baje impidiendo cumplir con el compromiso establecido en el Sprint Planning; resultando en una pérdida o disminución de credibilidad de los Stake Holders hacia el equipo de Scrum y una frustración de los miembros del equipo.

 Existen diferentes formas en las que podemos ayudar a nuestras equipos de Scrum a sobrellevar estos problemas y aquí me gustaría hablar de 2 formas que me han resultado útiles.

1. Interrupt Buffer

En el libro “A Scrum Book, The Spirit of the Game” por Jeff Sutherland (cocreador de Scrum) y James O. Coplien, los autores recomiendan el uso de un patrón llamado el Interrupt Buffer. Esto es algo sumamente sencillo de usar pero muy poderoso, debes de hacer lo siguiente: 

1. El equipo crea un colchón de su capacidad reservado para improvistos (llamado Interrupt Buffer) basado en data histórica, si últimamente un tercio del trabajo del equipo ha venido de trabajo no planeado y el promedio de velocidad del equipo es de 60 puntos, entonces crean un buffer de interrupción de 20 puntos (es decir en el próximo Sprint Planning solo pueden aceptar planear 40 puntos).
2. Todos los requisitos para solucionar los imprevistos deben ser trasladados al Product Owner. El Product Owner a medida de lo posible, debe de evitar interrumpir a los developers, excepto si la emergencia trae consecuencias graves para el área de negocio. Basado en su entendimiento el puede:
   
   • Agregar el PBI del imprevisto al Buffer de Interrupción (en este caso el equipo se dedicará a resolver este ítem durante el Sprint)
   • Agregar el PBI al Product Backlog y priorizarlo para ser tratado en un futuro Sprint.
3. Si la suma de las estimaciones de los ítems agregados al Interrupt Buffer es mayor al buffer, es necesario cancelar el Sprint y llamar a un Sprint Planning de inmediato con el Product Backlog Re-priorizado.

Pros:

• Aprenderás a comprometerte con lo que exactamente puedes lograr en el planning no aceptando más de lo que puedes, por que sabes exactamente cuantos story points necesitas durante el Sprint para atender improvistos.
• Lograrás con mucha más frecuencia cumplir con el compromiso que hiciste en el planning

Contras:

• Tendrás que estimar los PBIs imprevistos en story points, y esto te quitará aún más tiempo.

Tip:

• Si bien estimaste los PBIs que entran de emergencia, NO los cuentes en la velocidad de tu Sprint. Recuerda que la velocidad del Sprint debe reflejar la cantidad de trabajo planeado que tu equipo logra producir. Si incluyes a tu velocidad los  story points de estos ítems, solo te estas mintiendo a ti mismo con la falsa sensación de que como tu velocidad es alta, todo va bien.

2. Divide a tu equipo de Scrum

En una de las empresas en las que trabajé hace algunos años, después de algunos Sprints fallidos, tomamos la decisión de “partir” el equipo de Scrum (de 8 developers) en dos:

• Un equipo de Scrum de 5 developers dedicados a construir el producto
• Un equipo de 3 developers usando Kanban con dos misiones igualmente importantes:
  • Arreglar todos los bugs y tratar todos los ítems no planeados urgentes
  • Evitar a toda costa que se interrumpa al equipo de Scrum.

Como resultado de este experimento el equipio de Scrum logró duplicar su velocidad desde el primer Sprint (aún cuando pasamos de 8 developers a 5).

Pros:

• No pierdes tiempo estimando los imprevistos (al menos no al principio)

Contras:

• Reducirás el tamaño de tu equipo de Scrum, por lo cuál para ciertos casos no será lo ideal

 Tip:

• Esto debe de ser temporal. Si bien esto nos ayudó muchísimo, esta no debe de ser tu solución definitiva. Esta bien tener un equipo apagando fuegos para que no se incendie tu oficina, pero lo ideal es entender porqué hay fuegos, y hacer lo necesario para que no inicien.

 En términos generales, los equipos de Scrum deben de entender de donde vienen estas interrupciones y no solo deben saber tratarlas, si no entender cómo reducirlas.

 Puede que esto venga por un producto que no tenga buenas prácticas de ingeniería y con el tiempo se vuelvan no mantenibles. Usar DevOps, test automation, y en general buenas pácticas te ayuden a reducir el numero de emergencias.

 Es posible que esto también venga del lado de negocio, un entorno muy cambiante o un mal entendimiento de lo que realmente necesita el usuario final.

En este caso será necesario ayudar al PO a entender cómo gestionar estos entornos educando a la organización en Scrum y mostrándole técnicas que le permitan tener un “norte” claro de hacía donde guiar el barco.