¿Cómo funciona Scrum de Scrums?

Scrum de Scrums está compuesto de representantes de los equipos

Scrum de Scrums es una primera aproximación al escalado presentada por Jeff Sutherland en 2001, un complemento para Scrum no considerado como parte de Scrum y que por tanto no se menciona en la Scrum Guide. Trata de una técnica para usar Scrum de forma escalada cuando varios equipos trabajan en un único producto o una familia de productos única.

Recordemos que los equipos de Scrum no deben de superar los 9 miembros para ser eficientes y para que funcione la autoorganización. Si un producto requiere a más de 9 desarrolladores, en vez de hacer crecer a un equipo existente, el enfoque de Agilidad es crear varios equipos y distribuir el trabajo entre todo ellos. Para ello necesitamos una forma efectiva para la coordinación, el alineamiento y la comunicación entre estos equipos, así como una integración de las entregas a final de sprint.

Scrum de Scrums nos da solución a estas necesidades. Su formato es similar a la reunión diaria, en la que en vez de los equipos, son los miembros los que se sincronizan y alinean dentro de su equipo. Scrum de Scrums se puede celebrar de forma diaria, dos veces a la semana o al menos una vez a la semana. El día que se haga deberá de ser justo después de las reuniones diarias, por tanto será preferible que los equipos celebren sus reuniones diarias en paralelo.

Acabada la reunión diaria un representante de cada equipo acude al Scrum de Scrums, este debe de ser el miembro del equipo que más involucrado esté con el desarrollo del objetivo del sprint, por tanto a sucesivos Scrum de Scrums pueden acudir diferentes representantes. La reunión no debe de superar los 30 minutos, y aunque facilitada por un Scrum Master, los equipos no pueden estar representados por su Scrum Master o su Propietario del Producto. En Scrum de Scrums es necesario que el representante tenga poder de decisión como equipo de desarrollo y que los compromisos adquiridos los adquiera en nombre de su equipo.

Cada representante responde de forma escalada a las tres preguntas estándar de las diarias, más una pregunta extra:

• ¿Qué hizo mi equipo de desarrollo desde la última reunión para lograr su objetivo del sprint?
• ¿Qué hará mi equipo de desarrollo antes de la siguiente reunión para lograr su objetivo del sprint?
• ¿Hay algún impedimento que esté afectando negativamente a mi equipo de desarrollo y que impacte en el objetivo del sprint?
• ¿Hay algo de mi equipo de desarrollo que se pueda interponer o afectar al objetivo del sprint de los demás equipos?

La pregunta añadida es la que coordina y alinea, trata las dependencias y bloqueos que el trabajo de un equipo podría generar para los demás. Para reducir dependencias y bloqueos es una práctica esencial en escalado mantener las historias de usuario de pila de producto lo más independientes posible.

Una vez todos hayan respondido a las cuatro preguntas la reunión pone el foco en tratar una lista de temas pendientes más los detectados en el Scrums de Scrums reciente. Esta lista deberá de estar recogida por ejemplo en una hoja de rotafolios y post-its, un excel, una wiki...

Fijémonos que con equipos no superiores a 9 miembros, y reuniones de Scrum de Scrums con no más de 9 representantes, podemos escalar con esta técnica a 9X9 = 81 personas. Podemos añadir una nueva capa de escalado para el modelo e incluir un Scrum de Scrums de Scrums. No debemos de superar el número de Dunbar de aproximadamente un total de 150 personas. Es el límite que impone nuestro tamaño de la neocorteza cerebral y su capacidad de proceso, según el antropólogo Robin Dunbar no podemos relacionarnos plenamente en una red social (familia, amigos, profesional, virtual...) por encima de esa cantidad de personas.

---

Otros marcos de escalado incluyen en sus prácticas Scrum de Scrums. En SAFe la reunión ayuda a coordinar las dependencias del ART (Agile Release Train) y proporciona visibilidad de progreso e impedimentos. El RTE (Release Train Engineer) facilita, Scrum Masters y otros (cuando corresponda) se reúnen y revisan el progreso para con los hitos, los objetivos de PI y las dependencias internas entre equipos. La composición de los asistentes es algo distinta al Scrum de Scrums original. En SAFe las dependencias se hacen visibles en el primer momento y se habrán resuelto en la PI Planning, a la vez que existen otros mecanismos de coordinación y alineamiento como son la PO-Sync por ejemplo. Por tanto es suficiente que los Scrum Masters gestionen la coordinación y el alineamiento del tren, en caso de detección de nuevas dependencias o nuevos bloqueos éstos incorporan en la reunión a miembros de los equipos afectados.