¿Qué es Scrum@Scale y para qué sirve?

Scrum@Scale® está diseñado para escalar la productividad de los equipos de Scrum, y hacer que toda la organización entregue el doble de valor a la mitad del costo. Permite implementar un flujo de trabajo optimizado a un ritmo sostenible, tomar decisiones más eficientemente, mejorar el ambiente de trabajo, aumentar la agilidad de negocio, y generar mayores ganancias para todos los stakeholders.

Scrum@Scale® permite generar la coordinación y comunicación necesarias para que redes de equipos de Scrum trabajen de forma consistente con la Guía de Scrum, solucionen problemas complejos y creen productos con el máximo valor posible.

Vamos a ver de qué se trata Scrum@Scale® y cómo nos permite escalar Scrum sin pérdidas de productividad por burocracia. 

¿Por qué es importante tener un marco de escalamiento?

Los equipos de Scrum son pequeños (máximo 9 personas) y en una organización, cuando queremos realizar más trabajo, con seguridad necesitamos varios equipos de Scrum que deben trabajar de forma coordinada. En Saab Aeronautics, por ejemplo, se tienen miles de ingenieros desarrollando el avión Grippen, que están organizados en cientos de equipos con Scrum@Scale® y entregan una versión mejorada del avión a cada tres semanas.

Cuando trabajamos con Scrum, se evidencian impedimentos y cuellos de botella que retrasan la entrega, producen desperdicios o impiden la agilidad del negocio y sin un marco de escalamiento ágil la organización logra solamente una “agilidad operacional” con equipos practican Scrum pero mantienen los mayores impedimentos para ser ágiles. Estos impedimentos están en la organización y en su estructura organizacional. La forma más eficaz y efectiva de eliminar estos problemas y tener una “agilidad organizacional” es extender Scrum a toda la organización, así toda la cadena de valor se optimiza y los beneficios del agilismo serán mucho mayores.

El desafío del escalamiento

Antes de hablar de Scrum@Scale® quiero introducir dos conceptos: la “escalabilidad Lineal” y la “mínima burocracia viable”. Estos conceptos tienen que ver con la productividad o pérdida de productividad debido a la burocracia. Cuando tenemos varios equipos de Scrum es necesario tener una cierta burocracia para coordinación y comunicación porque de otra manera los equipos no van a trabajar hacia un mismo objetivo y vamos a tratar todas las particularidades de los equipos de forma individual e ineficientemente. El resultado de productividad que esperamos cuando tenemos varios equipos es, por ejemplo, el doble de productividad cuando duplicamos los equipos y 4 veces la productividad cuando tenemos 4 equipos en vez de un equipo.

Pero este aumento lineal de productividad no es tan simple de lograr, porque mientras más equipos y personas tengamos mayor será el esfuerzo para coordinarlos. Este esfuerzo no es productivo en sí, o sea no agrega valor al producto y se llama burocracia. Al escalar los equipos de Scrum queremos tener la mínima burocracia viable, o sea lo mínimo de reuniones y actividades de coordinación y comunicación necesarias y queremos tener una escalabilidad lineal que haga crecer el resultado de los equipos directamente proporcional a la cantidad de equipos de Scrum. Esto se puede obtener solamente con marcos de escalamiento que no agreguen burocracia adicional ni elementos nuevos a Scrum, como Scrum@Scale®.

El equipo de Scrum Escalado

Con Scrum@Scale® tenemos equipos de Scrum escalados que los denominamos Scrum de Scrums, en donde representantes de cada equipo participan y tienen las versiones escaladas de los roles, eventos y artefactos de Scrum. Los equipos escalados son responsables de que cada uno de los incrementos de los equipos participantes se integren en un único incremento de producto al final de cada sprint. Si la organización es grande se puede requerir tener equipos escalados los Scrum de Scrums (SoS) y de esta forma se puede escalar orgánicamente en grandes organizaciones.

En la figura vemos un Scrum de Scrums que permite coordinar 5 equipos que típicamente tendrían 25 personas, y un Scrum de SoS (SoSoS) que permite coordinar 5 grupos cada uno con 5 equipos que tiene en total aproximadamente 125 personas.

Componentes de Scrum@Scale®

Scrum@Scale® contiene dos ciclos: el Ciclo del Scrum Master (el “cómo”) y el Ciclo del Product Owner (el “qué”), cada uno de estos ciclos se cruza con el otro en dos puntos. Estos dos ciclos producen un marco poderoso para coordinar y sincronizar los esfuerzos de múltiples equipos.

 El Ciclo Scrum Master: el “cómo”

Antes de contarte sobre el ciclo del Product Owner, debes saber; para tomar un entrenamiento de Scrum@Scale se requiere experiencia como Scrum Master o Product Owner, ¿quieres saber cómo iniciar tu camino en Scrum? Conoce más aquí

Si ya conoces Scrum, te será muy fácil entender este ciclo, porque la lógica de funcionamiento es la misma que un equipo de Scrum.

En el ciclo del Scrum Master el equipo Scrum de Scrums (SoS) es responsable de un conjunto completamente integrado de incrementos de producto potencialmente enviables al final de cada Sprint de todos los equipos participantes. Esto significa que el SoS tiene roles, artefactos y eventos, y actúa efectivamente como un equipo de lanzamiento, con mucha responsabilidad. Este equipo, al igual que todos los equipos de Scrum debe ser de 3 a 5 personas con una persona desempeñando un rol de Scrum Master y otra el rol de Product Owner.

En estructuras grandes se necesita un equipo de toma de decisiones que haga las funciones del Scrum Master de toda la organización. Este equipo es el Executive Action Team (EAT). El EAT es la parada final para los impedimentos que los SoS no pueden eliminar. Por lo tanto, debe estar compuesto por personas que estén empoderadas, política y financieramente, para eliminarlos. La función del EAT es coordinar múltiples SoS (o SoSoS) e interactuar con cualquier parte no ágil de la organización. Al igual que con cualquier equipo Scrum, necesita un Product Owner y Scrum Master. Idealmente el EAT se reúne diariamente al igual que cualquier equipo Scrum y debe reunirse al menos una vez por Sprint y tener lista priorizada de impedimentos que sea transparente para toda la organización.

El resultado del ciclo del Scrum Master es:
• Mejora continua y eliminación de impedimentos
• Coordinación entre equipos
• Despliegue.

Conoce más sobre Comunicación para el Scrum Master en equipos multiculturales

El ciclo del Product Owner: el “qué”

Antes de contarte sobre el ciclo del Product Owner, debes saber; para tomar un entrenamiento de Scrum@Scale se requiere experiencia como Scrum Master o Product Owner, ¿quieres saber cómo iniciar tu camino en Scrum? Conoce más aquí

Para cada Scrum de Scrums, hay un Backlog (lista) compartido común que alimenta a la red de equipos y garantiza que las prioridades de todos los equipos estén alineadas con las prioridades macro de la organización y las necesidades de los stakeholders y clientes. La gerencia de este Backlog compartido y el alineamiento con los backlogs de cada equipo necesita de un Equipo de Product Owners (Equipo de POs) que debe tener un Chief Product Owner que es la autoridad final.

La principal función del Equipo de POs es garantizar que el Backlog compartido refleje la visión de producto y esté alineado con los stakeholders y que las prioridades de los backlogs individuales de los equipos estén alineadas con el Backlog compartido.

Al igual que en el ciclo del Scrum Master tenemos el EAT, que es un grupo que cumple las funciones del “Scrum Master de la Organización”, en el ciclo del Product Owner tenemos el Meta Scrum Ejecutivo (EMS), que es un grupo dinámico de líderes que cumple las funciones de “Product Owner de la Organización” y establece la visión organizacional y las prioridades estratégicas, alineando a todos los equipos con los objetivos en común.

El resultado del ciclo del Product Owner es:
• Definir, mantener y comunicar la visión estratégica.
• Priorización del Backlog de la organización.
• Descomposición y Refinamiento del Backlog para que cada equipo los pueda desarrollar.
• Planificación de los lanzamientos.

La conexión entre los dos ciclos

Los mecanismos de conexión entre el ciclo Scrum Master y el ciclo del Product Owner son la retroalimentación y las métricas.

La retroalimentación del producto impulsa la mejora continua mediante el ajuste del Product Backlog, mientras que la retroalimentación sobre el proceso del lanzamiento impulsa la mejora continua mediante el ajuste de los mecanismos de implementación.

Scrum@Scale® no requiere ningún conjunto específico de métricas, pero sugiere que como mínimo, la organización debería medir:

• Productividad, por ejemplo: cambio en la cantidad de Producto de trabajo entregado por Sprint
• Entrega de valor, por ejemplo: el valor comercial por unidad de esfuerzo en equipo
• Calidad, por ejemplo: la tasa de defectos o tiempo de inactividad del servicio
• Sostenibilidad, por ejemplo: felicidad del equipo

¿Cómo aprender más sobre Scrum@Scale®? 

La guía de Scrum@Scale® te permite profundizar en estos conceptos, y es de fácil lectura y está en varios idiomas incluyendo español

¿Quieres saber más sobre nuestro entrenamiento formal de Scrum@Scale®?.

Dos días online en español, con certificación oficial del Dr. Jeff Sutherland. Más info en Entrenamiento Online Certified Scrum@Scale® Practitioner