Escalado básico: Scrum de Scrums

Scrum impone una limitación a los proyectos, y esta es el tamaño de los equipos. La máxima cantidad de miembros es 9. Existen muy buenas razones, como la eficiencia, la autoorganización o el crecimiento exponencial de la red de comunicaciones. Si un producto requiere más desarrolladores, en lugar de aumentar un equipo existente, podemos crear varios y distribuir el trabajo entre ellos. Para ello, necesitamos una estrategia de coordinación, alineamiento, comunicación e integración del incremento al final de cada iteración.

¿Cómo acometer entonces un proyecto de gran tamaño? ¿De qué manera puede crecer el uso de metodologías ágiles en una organización? La respuesta requiere un enfoque no incluído en el marco de trabajo, que es Scrum ofScrums, o SoS. Es posible definirlo como una técnica para usar Scrum de forma escalable, cuando varios equipos trabajan en un producto único o una familia de productos homogénea.

Jeff Sutherland menciona SoS como un complemento que no es parte del marco original, por lo que no aparece en la Guía oficial. 

La situación que originó este enfoque fue la necesidad de coordinar y sincronizar varias unidades de negocio individuales, con múltiples líneas de productos. Las conclusiones fueron publicadas en 2001 en el artículo “La metodología ágil se puede escalar: invención y reinvención de scrum en cinco empresas“, en el que menciona por primera vez el concepto.

Scrum of Scrums nos da la solución a esta problemática. Con un formato similar a la daily meeting, en la que, en vez de los miembros, son los equipos los que se sincronizan. Los participantes son embajadores de cada uno de ellos.

Tal vez te interese leer: Ceremonias Scrum – Daily Meeting

Agenda

Cada integrante comenta de manera breve y concisa

• ¿Qué actividades ha ejecutado tu equipo desde la última reunión? 
• ¿Qué actividades realizará antes de la próxima reunión?
• ¿Existen bloqueos o impedimentos? 
• ¿Existe alguna actividad a ejecutar próximamente por tu equipo que interfiera o afecte el trabajo del resto? 

La última pregunta es la que coordina y alinea, trata las dependencias y bloqueos que el trabajo de un equipo podría generar en el resto. Para reducir esto es fundamental crear las historias de usuario lo más independientes posible.

La intención es que la exposición de cada integrante sea breve y concisa. Los problemas se pueden mencionar, pero no se buscan soluciones hasta que todos hayan hecho su intervención.

Scrum of Scrums se puede celebrar de forma diaria, en días alternos o semanalmente. Por lo general, se realiza luego que los equipos celebran sus reuniones diarias en paralelo. 

A las sucesivas ceremonias pueden entonces acudir diferentes miembros cada vez. Es posible rotar según la etapa del proyecto y quien esté en mejor posición para contribuir con la reunión. Es necesario que los participantes tengan poder de decisión y que los compromisos adquiridos sean en nombre del equipo.

La reunión está facilitada por un Scrum Master, pero los equipos no pueden estar representados por su Scrum Master o su dueño de producto. El facilitador no tiene responsabilidad directiva. El grupo SoS no realiza planificaciones de iteración ni revisiones de Backlogs. La intención es simple y sencilla: coordinar y sincronizar actividades. 

El equipo de representantes generará un Backlog de Scrum de Scrums, que consiste en una lista de incidencias o problemas comunes. Es conveniente que los elementos que no puedan ser resueltos de inmediato, se asignen a un kanban impedimentos y se designe un responsable.

Inmediatamente después, en una reunión separada, se resolverán los problemas identificados. Es recomendable reservar 30 minutos para esta tarea.

Tal vez te interese leer: Marcos de escalado ágil

Situaciones particulares

Recordemos que el marco subyacente sigue siendo Scrum. Hablamos siempre de equipos cross funcionales y autosuficientes. Una disfunción habitual es intentar dividir un gran equipo de trabajo ya en marcha en subunidades ágiles, donde cada una de ellas está especializada por función. Tendríamos por ejemplo la unidad de UX, la de los analistas, la de front end, la de back end, la de servicios, etcétera. Esto no es agile ni tampoco Scrum.

Otro inconveniente que puede surgir, es que al dividir un producto de gran tamaño, la cantidad de equipos sea muy alta, y en el SoS deban participar más de 10 miembros. En esta situación, es posible aplicar un enfoque fractal, y tener una primera etapa de coordinación de 3 o 4 unidades, y luego un representante de estos acudir a un nivel superior.

Tal vez te interese leer: Scrum@scale: fractal, sencillo y efectivo

Si estás interesado en conocer toda la variedad de estrategias de escalado, te recomendamos nuestra formación en Marcos de escalado ágil. Infórmate aquí hoy mismo.

Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial-SinObraDerivada 4.0 Internacional.