El Scrum@Scale® Guía

La Guía Definitiva del Scrum@Scale: Escalado que funciona

Prefacio de la Guía del Scrum@Scale

Scrum, tal y como se describe originalmente en la Guía de Scrum, se centra en que un único Equipo Scrum sea capaz de ofrecer un valor óptimo manteniendo un ritmo sostenible. Desde su creación, el uso de Scrum se ha extendido a la creación de productos, procesos y servicios que requieren los esfuerzos de múltiples equipos.

Sobre el terreno, se observó repetidamente que, a medida que crecía el número de Equipos Scrum dentro de una organización, surgían dos problemas importantes:

• El volumen, la velocidad y la calidad de su producción (producto de trabajo) por equipo comenzó a disminuir, debido a problemas como las dependencias entre equipos, la duplicación del trabajo y la sobrecarga de comunicación
• La estructura de gestión original era ineficaz para lograr la agilidad del negocio. Surgieron problemas como la competencia de prioridades y la incapacidad de cambiar rápidamente los equipos para responder a las condiciones dinámicas del mercado

Para contrarrestar estos problemas, era evidente que se necesitaba un marco para coordinar eficazmente varios Equipos Scrum que tuviera como objetivo lo siguiente

• Escalabilidad lineal: Un aumento porcentual correspondiente en la entrega del producto de trabajo con un aumento en el número de equipos
• Agilidad empresarial: La capacidad de responder rápidamente al cambio adaptando la configuración estable inicial

Scrum@Scale ayuda a una organización a centrar múltiples redes de Equipos Scrum en objetivos prioritarios. Para ello, establece una estructura que amplía de forma natural el funcionamiento de un único Equipo Scrum en una red y cuya función directiva existe dentro de una burocracia mínima viable (MVB).

Una red puede alcanzar la escalabilidad lineal cuando sus características son independientes de su tamaño. Diseñar y coordinar una red de equipos con este objetivo no limita el crecimiento de una forma concreta, sino que permite que la red crezca de forma orgánica, en función de sus necesidades únicas, y a un ritmo de cambio sostenible que pueda ser mejor aceptado por las personas implicadas.

Una burocracia mínima viable se define como la que tiene la menor cantidad de órganos de gobierno y procesos necesarios para llevar a cabo la(s) función(es) de una organización sin impedir la entrega de valor al cliente. Ayuda a conseguir la agilidad del negocio reduciendo la latencia de las decisiones (el tiempo para tomar una decisión), lo que se ha señalado como un motor principal del éxito. Para empezar a aplicar el Scrum@Scale, es esencial conocer el Manifiesto Ágil y la Guía Scrum 2020. No entender la naturaleza de la agilidad impedirá que se consiga. Si una organización no puede hacer Scrum, no puede escalar.

Finalidad de la Guía Scrum@Scale

Esta guía proporciona la definición de Scrum@Scale y los componentes de su marco. Explica las responsabilidades de los roles escalados, los eventos escalados y los artefactos empresariales, así como las reglas que los unen.

Esta guía se divide en cuatro secciones básicas:

• una introducción al Scrum@Scale, con lo básico para empezar
• una visión general del Ciclo Scrum Master
• una visión general del Ciclo Product Owner
• un recorrido para reunir los ciclos

Cada componente sirve para un propósito específico que se requiere para el éxito a escala. Cambiar su diseño o ideas principales, omitirlas o no seguir las reglas básicas establecidas en esta guía limita los beneficios de Scrum@Scale.

Las tácticas específicas que van más allá de la estructura básica y las normas de aplicación de cada componente varían y no se describen en esta Guía. Otras fuentes proporcionan pautas, procesos y conocimientos complementarios.

Definiciones

Scrum es un marco ligero que ayuda a las personas, los equipos y las organizaciones a generar valor a través de soluciones adaptativas para problemas complejos.

La Guía Scrum describe el conjunto mínimo de elementos que crean un entorno de equipo que impulsa la innovación, la satisfacción del cliente, el rendimiento y la felicidad. Scrum utiliza una transparencia radical y una serie de eventos formales para ofrecer oportunidades de inspeccionar y adaptar un equipo y su(s) producto(s).

El Scrum@Scale es un marco organizativo ligero en el que una red de equipos que operan de forma coherente con la Guía Scrum puede abordar problemas adaptativos complejos, a la vez que ofrece de forma creativa productos del mayor valor posible. Estos "productos" pueden ser físicos, digitales, sistemas integrados complejos, procesos, servicios, etc.

La Guía Scrum@Scale describe el conjunto mínimo de componentes para escalar Scrum utilizando Scrum y su agilidad empresarial resultante en toda una organización. Puede utilizarse en todo tipo de organizaciones dentro de la industria, el gobierno, las organizaciones sin ánimo de lucro o el mundo académico. Si una organización no utiliza ya Scrum, requerirá cambios en su sistema operativo.

En Scrum, se tiene cuidado de separar la responsabilidad del "qué" (producto) del "cómo" (proceso). El mismo cuidado se tiene en el Scrum@Scale, para que la jurisdicción y la responsabilidad se entiendan expresamente. Esto elimina los conflictos organizativos inútiles que impiden a los equipos alcanzar su productividad óptima. Como el Scrum@Scale consta de componentes, permite a una organización personalizar su estrategia de transformación y su aplicación. Ofrece a una organización la capacidad de orientar los esfuerzos de cambio de forma incremental y prioritaria en el área o áreas que se consideren más valiosas o más necesitadas de adaptación, para luego pasar a otras.

El Scrum@Scale separa estos componentes en dos ciclos: el Ciclo Scrum Master (el "cómo") y el Ciclo Product Owner (el "qué"), que se cruzan en dos componentes y comparten un tercero. Tomados en su conjunto, estos ciclos producen una poderosa estructura de apoyo para coordinar los esfuerzos de múltiples equipos a lo largo de un mismo camino.

Los componentes del Scrum@Scale

Cultura orientada a los valores

El Scrum@Scale pretende construir una cultura organizativa saludable a través de los pilares del control empírico de procesos y los Valores Scrum. Los pilares del control empírico del proceso son la transparencia, la inspección y la adaptación. Estos pilares se actualizan con los valores Scrum de Apertura, Valor, Enfoque, Respeto y Compromiso.

La apertura favorece la transparencia en todo el trabajo y los procesos y, sin ella, no hay capacidad para inspeccionarlos honestamente e intentar adaptarlos para mejorarlos. La valentía se refiere a dar los audaces saltos necesarios para aportar valor más rápidamente de forma innovadora. El enfoque y el compromiso se refieren a la forma en que manejamos nuestras obligaciones laborales, poniendo la entrega de valor al cliente como máxima prioridad. Por último, todo esto debe ocurrir en un entorno basado en el respeto a las personas que realizan el trabajo, sin las cuales no se puede crear nada.

Scrum@Scale ayuda a las organizaciones a prosperar apoyando un entorno positivo de aprendizaje en equipo para trabajar a un ritmo sostenible, al tiempo que pone el valor del cliente en primer plano.

Cómo empezar: Instalar un sistema operativo ágil

Al implantar redes de equipos, es fundamental desarrollar un Modelo de Referencia escalable antes de escalar. El modelo de referencia es un pequeño conjunto de equipos que se coordinan para entregar cada Sprint. A medida que estos equipos implementan Scrum con éxito, el resto de la organización tiene un ejemplo funcional y saludable de Scrum para replicar. Sirve como prototipo para escalar Scrum en la siguiente red de equipos. Cualquier deficiencia en la implantación de Scrum se magnificará cuando se desplieguen varios equipos. Los problemas de escalado incluyen políticas y procedimientos organizativos o prácticas de desarrollo que bloquean el rendimiento y frustran a los equipos.

En un entorno a escala, la mejor manera de hacer posible el Modelo de Referencia es agrupar a los equipos que necesitan coordinarse para entregar un conjunto de incrementos totalmente integrados en un Scrum de Scrums (SoS). Para funcionar eficazmente, el Scrum de Scrums necesita el apoyo de una burocracia mínimamente viable compuesta por dos grupos de liderazgo: un foro de MetaScrum Ejecutivo (EMS), centrado en lo que produce el Scrum de Scrums y un Equipo de Acción Ejecutivo (EAT) centrado en cómo pueden hacerlo más rápido. Los componentes del MetaScrum Ejecutivo y del Equipo de Acción Ejecutivo son los ejes en torno a los cuales gira cada ciclo.

Escalar los equipos

En Scrum, el estado ideal es que un Equipo Scrum sea un camino independiente hacia la producción. Como tal, necesita miembros que tengan todas las habilidades necesarias para pasar de la ideación a la implementación. El Scrum de Scrums es un equipo más grande de múltiples equipos que replica este ideal a escala. Cada equipo dentro del Scrum de Scrums debe satisfacer el componente de Proceso de Equipo.

El proceso del equipo

El Proceso del Equipo es Scrum tal y como lo prescribe la Guía Scrum. Como todo Equipo Scrum tiene un Product Owner y un Scrum Master, constituye la primera intersección entre los Ciclos Product Owner y Scrum Master. Los objetivos del Proceso de Equipo son

• Maximizar el flujo de trabajo completado que cumple con la Definición de Hecho
• Aumentar el rendimiento del equipo a lo largo del tiempo
• Operar de forma sostenible y enriquecedora para el equipo
• Acelerar el ciclo de retroalimentación del cliente

El Scrum de los Scrums (SoS)

Un Scrum de Scrums funciona como si fuera un Equipo Scrum, satisfaciendo el componente de Proceso de Equipo con versiones escaladas de las responsabilidades, eventos y artefactos de Scrum. Aunque la Guía de Scrum define el tamaño óptimo del equipo como inferior a 10 personas, la investigación de Harvard ha determinado que el tamaño óptimo del equipo es de 4,6 personas (de media). Por tanto, el número óptimo de equipos en un Scrum de Scrums es de 4 ó 5.

Como grupo dinámico, los equipos que componen el Scrum de Scrums son responsables de un conjunto totalmente integrado de incrementos de producto potencialmente enviables al final de cada Sprint. De forma óptima, llevan a cabo todas las funciones necesarias para liberar valor directamente a los clientes.

NOTA: En el diagrama anterior y en los siguientes, los pentágonos con contorno gris claro representan un equipo. En su caso, hemos optado por representar al SM y al PO como pentágonos más pequeños. Estos diagramas son sólo ejemplos, ya que cada diagrama organizativo puede ser muy diferente.

Escalar en organizaciones más grandes

Dependiendo del tamaño de una implementación, puede ser necesario más de un Scrum de Scrums para entregar un producto complejo. En estos casos, se puede crear un Scrum de Scrums (SoSoS) a partir de múltiples Scrums de Scrums. Cada uno de ellos tendrá versiones a escala de los roles, artefactos y eventos de cada Scrum de Scrums.

La escalabilidad del Scrum de Scrums reduce el número de vías de comunicación dentro de la organización, de modo que se limita la complejidad de la sobrecarga de comunicación. El SoSoS interactúa con un Scrum de Scrums exactamente de la misma manera que un Scrum de Scrums interactúa con un único Equipo Scrum, lo que permite una escalabilidad lineal.

NOTA: Para simplificar, el número de equipos y las agrupaciones en los diagramas de muestra son simétricos. Sólo pretenden ser ejemplos, ya que cada diagrama organizativo puede ser muy diferente.

Escalar los eventos y los roles

Si un Scrum de Scrums (SoS) funciona como un Equipo Scrum, entonces necesita escalar los Eventos Scrum y las correspondientes responsabilidades de los equipos. Para coordinar el "cómo" en cada Sprint, un SoS tendrá que celebrar versiones a escala del Scrum Diario y de la Retrospectiva del Sprint. Para coordinar el "qué" en cada Sprint, un SoS tendrá que celebrar versiones escaladas de la Planificación del Sprint y de la Revisión del Sprint. Como práctica continua, el refinamiento del backlog también tendrá que hacerse a escala.

Las versiones escaladas del Scrum Diario y la Retrospectiva son facilitadas por un Scrum Master para el grupo, llamado Scrum of Scrums Master (SoSM). Las versiones escaladas de la Revisión del Sprint y el Refinamiento del Backlog son facilitadas por un Equipo Product Owner guiado por un Jefe Product Owner (CPO). La versión a escala de la Planificación del Sprint se lleva a cabo con el Equipo Product Owner y el Scrum Masters. El Equipo Product Owner obtiene información sobre lo que se entregará en el Sprint actual y el Scrum Masters obtiene información sobre la capacidad y las capacidades técnicas. Los papeles del Scrum of Scrums Master y del Jefe Product Owner escalan a los grupos de liderazgo que luego impulsan sus correspondientes ciclos, satisfaciendo los componentes del Scrum@Scale.

Evento: El Scrum Diario Escalado (SDS)

Los principales puntos de discusión de un Scrum Diario son el progreso hacia el Objetivo del Sprint y los impedimentos para cumplir ese compromiso. En un entorno escalado, el Scrum de Scrums necesita comprender el progreso colectivo y ser receptivo a los impedimentos planteados por los equipos participantes; por lo tanto, al menos un representante de cada equipo asiste a un Scrum Diario Escalado (SDS). Cualquier persona o número de personas de los equipos participantes puede asistir según sea necesario.

Para optimizar la colaboración y el rendimiento, el evento Scaled Daily Scrum es un reflejo del Daily Scrum, ya que

• Está limitado a 15 minutos o menos
• Debe asistir un representante de cada equipo.
• Es un foro para debatir cómo los equipos pueden trabajar juntos de forma más eficaz, qué se ha hecho, qué se va a hacer, qué va mal y por qué, y qué va a hacer el grupo al respecto

Algunos ejemplos de preguntas que hay que responder:

• ¿Qué impedimentos tiene el equipo que le impedirán cumplir su Objetivo del Sprint o que afectarán al plan de entrega?
• ¿Un equipo está haciendo algo que impedirá a otro equipo cumplir su Objetivo del Sprint o que afectará a su plan de entrega?
• ¿Se han descubierto nuevas dependencias entre los equipos o una forma de resolver una dependencia existente?

Evento: La retrospectiva de Scaled

Cada Sprint, el Scrum de los Scrums celebra una versión ampliada de la Retrospectiva del Sprint en la que los Scrum Masters de cada equipo se reúnen y discuten qué experimentos se han realizado para impulsar la mejora continua y sus resultados. Además, deben discutir la siguiente ronda de experimentos y cómo se pueden aprovechar las mejoras exitosas en todo el grupo de equipos o más allá.

El ciclo Scrum Master: Coordinar el "cómo"

Función: El Scrum of Scrums Master (SoSM)

El Scrum Master del Scrum de Scrums se llama Scrum of Scrums Master (SoSM). El Scrum of Scrums Master es responsable de garantizar que los eventos de Scrum of Scrums se celebren, sean productivos, positivos y se mantengan dentro del plazo previsto. El Scrum of Scrums Master puede ser uno de los Scrum Masters del equipo o una persona dedicada específicamente a esta función. Es responsable de la liberación de los esfuerzos de los equipos conjuntos y de la mejora continua de la eficacia del Scrum de Scrums. Esto incluye un mayor rendimiento del equipo, un menor coste y una mayor calidad. Para lograr estos objetivos, deben:

• Trabaja en estrecha colaboración con el Jefe Product Owner para entregar un incremento de producto potencialmente liberable al menos cada Sprint
• Coordinar la entrega de los equipos con los planes de liberación del Equipo Product Owners
• Hacer visibles para la organización los impedimentos, las mejoras del proceso y los avances
• Facilitar la priorización y eliminación de impedimentos, prestando especial atención a las dependencias entre equipos

El Scrum of Scrums Master es un verdadero líder que sirve a los equipos y a la organización comprendiendo las dependencias entre equipos, incluidos los que están fuera del Scrum of Scrums, y permitiendo la coordinación y comunicación entre equipos. Es responsable de mantener informados al Jefe Product Owner, a las partes interesadas y a la organización en general, transmitiendo información sobre el progreso del desarrollo del producto, el estado de eliminación de los impedimentos y otras métricas. El Scrum of Scrums Master predica con el ejemplo, orientando a otros para aumentar la eficacia y la adopción de Scrum en toda la organización.

En el caso de que varios Scrums de Scrums se agrupen en un Scrum de Scrums de Scrums, entonces se necesita un Scrum de Scrum de Scrums Master (SoSoSM) para coordinar desde esa perspectiva más amplia.

El centro del ciclo de la SM: El Equipo de Acción Ejecutiva (EAT)

El Equipo de Acción Ejecutiva (EAT) cumple las responsabilidades del Scrum Master para toda una organización ágil. Este equipo de liderazgo crea un ecosistema ágil que permite que el Modelo de Referencia funcione de forma óptima, mediante:

• aplicar los valores de Scrum
• asegurar que se crean y apoyan los roles de Scrum
• Se celebran eventos de Scrum y se asiste a ellos
• Los artefactos Scrum y sus compromisos asociados se generan, se hacen transparentes y se actualizan a lo largo de cada Sprint.
• formular directrices y procedimientos que actúen como capa de traducción entre el modelo de referencia y cualquier parte de la organización que no sea ágil.

El Equipo de Acción Ejecutiva es responsable de eliminar los impedimentos que no pueden ser eliminados por los miembros del Scrum de Scrums (o de la red más amplia). Por lo tanto, debe estar formado por personas que estén facultadas, política y financieramente, para eliminarlos. La función del Equipo de Acción Ejecutiva es coordinar los múltiples Scrums de Scrums (o redes más amplias) e interactuar con cualquier parte no ágil de la organización. Como cualquier Equipo Scrum, necesita un Product Owner, un Scrum Master y un backlog transparente.

Ejemplo de diagrama que muestra un EAT que coordina 5 agrupaciones de 25 equipos

Atrasos y responsabilidades de EAT

El producto del Equipo de Acción Ejecutiva (EAT) es la creación de un sistema operativo ágil para la organización. El EAT elabora un Product Backlog que consiste en iniciativas para la transformación continua de la organización con el fin de lograr el objetivo de una mayor agilidad empresarial. Este backlog también incluye las mejoras de los procesos que eliminan los impedimentos y las que hay que estandarizar.

Las responsabilidades del Equipo de Acción Ejecutiva incluyen, entre otras, las siguientes

• Crear un sistema operativo ágil para el Modelo de Referencia a medida que se extiende por la organización, incluyendo normas, procedimientos y directrices operativas corporativas que permitan la agilidad
• Garantizar la creación, financiación y apoyo de una organización Product Owner
• Medir y mejorar la calidad de Scrum en una organización
• Construir la capacidad dentro de una organización para la agilidad del negocio
• Crear un centro de aprendizaje continuo para los profesionales de Scrum
• Apoyar la exploración de nuevas formas de trabajo

La función del Equipo de Acción Ejecutiva es velar por que se lleve a cabo este retraso. Pueden hacerlo ellos mismos o facultar a otro grupo para que lo haga. Como el Equipo de Acción Ejecutiva es responsable de la calidad de Scrum dentro de la organización, toda la organización Scrum Master depende de él.

La organización del Scrum Master (Scrum Masters, Scrum del Scrum Masters y el Equipo de Acción Ejecutiva) trabaja en conjunto para implementar los componentes del Ciclo del Scrum Master. Estos componentes únicos son:

• Mejora continua y eliminación de impedimentos
• Coordinación entre equipos
• Entrega

Mejora continua y eliminación de impedimentos

Lo ideal es eliminar los impedimentos lo antes posible. Esto es fundamental para evitar la escalada de los propios impedimentos, y porque los impedimentos no resueltos pueden ralentizar la productividad. Por tanto, los objetivos de la Mejora Continua y la Eliminación de Impedimentos son

• identificar los impedimentos y replantearlos como oportunidades de mejora
• Garantizar la transparencia y la visibilidad en la organización para lograr el cambio
• mantener un entorno eficaz para priorizar y eliminar los impedimentos
• verificar que las mejoras han tenido un impacto positivo en las métricas del equipo y/o del producto

Coordinación entre equipos

Cuando se necesitan varios equipos para la creación de un producto compartido, se requiere una colaboración ágil para el éxito. Por tanto, los objetivos de la Coordinación entre Equipos son:

• Sincronizar procesos similares en varios equipos relacionados
• mitigar las dependencias entre equipos para que no se conviertan en impedimentos
• Mantener la alineación de las normas y directrices del equipo para una producción consistente

Entrega

Dado que el objetivo del Scrum de Scrums es funcionar como una sola unidad y liberar juntos, la forma de entregar el producto entra en su ámbito como grupo. El Equipo Product Owner determina tanto el contenido del lanzamiento como el momento óptimo para entregar el incremento a los clientes. Por tanto, los objetivos de la entrega para el Scrum de Scrums son

• entregar a los clientes un flujo constante de productos acabados valiosos
• integrar el trabajo de los diferentes equipos en un solo producto sin fisuras
• garantizar una experiencia de alta calidad para el cliente

El ciclo Product Owner: Coordinar el "qué"

Escalar el Product Owner - El ciclo del Product Owner

Para cada Scrum de Scrums, hay un backlog común compartido que alimenta la red de equipos. Se requiere un Equipo Product Owner (Equipo PO), que incluya un Jefe Product Owner, que sea responsable como Product Owner del grupo de equipos. El objetivo principal del Equipo PO es garantizar que las prioridades de los equipos individuales sigan un mismo camino. Esto les permite coordinar los atrasos de su equipo individual y crear una alineación con las partes interesadas y las necesidades del cliente.

El Product Owner de cada equipo es responsable de la composición y priorización del Sprint backlog de su equipo y puede extraer elementos del backlog común o generar elementos independientes del backlog a su discreción, según sea necesario para cumplir los objetivos empresariales.

Las principales funciones del Equipo Product Owner son

• comunicar la visión global del producto y hacerla visible a todos los miembros de la organización
• crear una alineación con las partes interesadas clave para asegurar el apoyo a la implementación de la cartera de pedidos
• generar una única cartera de pedidos priorizada, garantizando que se evite la duplicación del trabajo
• trabajar con el Scrum of Scrums Master para crear una "Definición de Hecho" mínimamente uniforme que se aplique a todo el equipo
• eliminar las dependencias planteadas por los equipos
• generar una hoja de ruta y un plan de lanzamiento coordinados
• controlar las métricas que permiten conocer el producto y el mercado

Función: El Jefe Product Owner (CPO)

El Jefe Product Owner coordina las prioridades con el Equipo Product Owner. Juntos alinean las prioridades de la cartera de pedidos con las necesidades de las partes interesadas y de los clientes. El CPO puede ser un Product Owner individual del equipo que también desempeñe esta función, o puede ser una persona dedicada específicamente a ello. Sus principales responsabilidades son las mismas que las de un Product Owner normal, ahora escaladas:

• Establecer una visión estratégica para todo el producto
• Creación de un único backlog priorizado para ser entregado por todos los equipos
• Decide qué métricas controlará el Equipo Product Owner
• Evaluar los comentarios de los clientes sobre el producto y ajustar la cartera de pedidos común en consecuencia
• Facilitar el evento MetaScrum (ver más abajo)

El Jefe Product Owner es responsable, junto con sus Scrum of Scrums Masters asociados, de la entrega eficiente de los incrementos de producto de acuerdo con el Plan de Lanzamiento.

Escalando el equipo Product Owner

Tener Equipos Product Owner permite un diseño de red de Product Owners que escala junto con su Scrum de Scrums asociado. No hay un término específico asociado a estas unidades expandidas, ni el Jefe Product Owners de las mismas tiene títulos específicos expandidos. Se anima a cada organización a desarrollar el suyo propio.

El centro del ciclo de la OP: El MetaScrum Ejecutivo (EMS)

Para desempeñar el papel de Product Owner para toda la organización ágil, el Jefe Product Owners se reúne con los ejecutivos y los principales interesados en un evento de MetaScrum Ejecutivo. Este evento se deriva del patrón MetaScrum. Es el foro para que el Liderazgo y otras partes interesadas expresen sus preferencias al Equipo PO, negocien las prioridades, modifiquen los presupuestos o realineen los equipos para maximizar la entrega de valor. En ningún otro momento del Sprint deben tomarse estas decisiones.

En el MetaScrum Ejecutivo, un grupo dinámico de líderes establece la visión organizativa y las prioridades estratégicas, alineando a todos los equipos en torno a objetivos comunes. Para que sea eficaz, el Jefe Product Owner facilita y el Product Owner de cada equipo (o un representante) debe asistir. Este evento se produce con la frecuencia necesaria -al menos una vez por Sprint- para garantizar un backlog alineado dentro del Scrum de Scrums. De forma óptima, este grupo de líderes funciona como un equipo de scrum.

En el caso de implantaciones más grandes en las que hay varios Scrums de Scrums, puede haber varios MetaScrums que tengan su backlog estratégico creado y priorizado en un MetaScrum Ejecutivo.

Coordinar el "qué" - El ciclo Product Owner

La organización del Product Owner (el Product Owners, el Jefe del Product Owners y el MetaScrum Ejecutivo) trabajan en conjunto para satisfacer los componentes únicos del Ciclo del Product Owner:

• Visión estratégica
• Priorización de la cartera de pedidos
• Descomposición y refinamiento de la cartera de pedidos
• Planificación de la liberación

Visión estratégica

Una visión convincente atrae tanto a los clientes como a los grandes empleados. Por tanto, formula una Visión Estratégica que se comunique, tanto externa como internamente, con los objetivos de:

• alinear a toda la organización en un camino compartido hacia adelante
• articular de forma convincente por qué existen la organización y sus productos
• claridad que permita la creación de Objetivos de Producto concretos
• describir lo que hará la organización para aprovechar los activos clave
• ser capaz de responder a la rápida evolución de las condiciones del mercado

Priorización de la cartera de pedidos

Una correcta priorización del backlog es esencial para que los equipos trabajen de forma coordinada para optimizar la entrega de valor. La competencia entre las prioridades crea desperdicios porque arrastra a los equipos en direcciones opuestas. Los objetivos de la priorización de la cartera de pedidos son:

• identificar una ordenación clara de los productos, las capacidades y los servicios que se deben prestar
• reflejar la creación de valor, la mitigación de riesgos y las dependencias internas en la ordenación de la cartera de pedidos
• priorizar las iniciativas de alto nivel en toda la organización ágil antes de la Descomposición y Refinamiento del Backlog

Descomposición y refinamiento de la cartera de pedidos

El backlog de un Jefe Product Owner contiene elementos de mayor alcance que el backlog de un equipo individual. Para sacar los elementos priorizados en los equipos individuales, puede ser necesario descomponerlos y comprenderlos mejor. Los objetivos de la Descomposición y Refinamiento del Backlog son:

• identificar los productos complejos, los proyectos y los Objetivos de Producto asociados que harán realidad la visión
• dividir esos productos y proyectos complejos en elementos independientes
• garantizar que todos los elementos del backlog puedan ser refinados por los equipos en elementos que puedan completar en un Sprint

Planificación de la liberación

La planificación de la versión puede abarcar una o varias versiones del producto para un cliente. Es un horizonte de planificación a más largo plazo que un único Sprint. Los objetivos de la Planificación de Versiones son:

• prever el calendario de entrega de los principales incrementos de producto y capacidades.
• comunicar las expectativas de entrega a las partes interesadas.
• comunicar el impacto financiero del calendario de entrega.

Conexión de los ciclos Product Owner y Scrum Master

Los ciclos se cruzan por primera vez en el componente del Proceso de Equipo. A partir de ahí, la responsabilidad del "qué" y el "cómo" se separan hasta que se entrega el producto hecho. Los ciclos vuelven a conectarse en el componente de Retroalimentación, donde se interpreta la respuesta del cliente al producto. Esto requiere métricas para tomar decisiones empíricas sobre la adaptación para el siguiente ciclo de entrega. Las organizaciones Product Owner y Scrum Master trabajan juntas para cumplir los requisitos de estos componentes.

Comentarios sobre el producto y la versión

La organización Product Owner interpreta los comentarios sobre el producto para impulsar la mejora continua del mismo mediante la actualización de la(s) cartera(s) de productos. La organización Scrum Master interpreta el feedback de la versión para impulsar la mejora continua de los mecanismos de entrega. Los objetivos de la obtención y el análisis del Feedback son:

• validar los supuestos
• entender cómo los clientes utilizan e interactúan con el producto
• captar nuevas ideas y requisitos emergentes para nuevas funcionalidades

Métricas y transparencia

Las métricas pueden ser exclusivas tanto de organizaciones concretas como de funciones específicas dentro de esas organizaciones. El Scrum@Scale no exige ningún conjunto específico de métricas, pero sí sugiere que, como mínimo, la organización debe medir:

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

La transparencia radical es esencial para que Scrum funcione de forma óptima, dando a la organización la capacidad de evaluar honestamente su progreso y de inspeccionar y adaptar sus productos y procesos.

Los objetivos de tener Métricas y Transparencia son

• proporcionar el contexto adecuado para tomar decisiones basadas en datos
• reducir la latencia de la decisión
• agilizar el trabajo requerido por los equipos, las partes interesadas o la dirección

Algunas notas sobre el diseño organizativo

El objetivo del diseño organizativo con Scrum@Scale es permitir que esté basado en componentes, como el propio marco. Esto permite reequilibrar o refactorizar los equipos en respuesta al mercado.

 

Diagramas de muestra:

Relaciones con el cliente, Legal / Cumplimiento, y Operaciones de Personas se incluyen aquí ya que son partes necesarias de las organizaciones y existirán como Equipos Scrum independientes por sí mismos, en los que todos los demás equipos pueden apoyarse.

Una última nota sobre la representación del Equipo de Acción Ejecutiva y el MetaScrum Ejecutivo: En este diagrama, se muestran como superpuestos, ya que algunos miembros forman parte del EAT y asisten al evento del SME. En organizaciones o implantaciones muy pequeñas, el Equipo Ejecutivo
Los miembros del Equipo de Acción y los asistentes al evento del MetaScrum Ejecutivo pueden estar formados en su totalidad por las mismas personas.

En este organigrama, los Equipos de Conocimiento e Infraestructura representan equipos virtuales de especialistas de los que hay muy poco personal en cada equipo. Si actúan como equipo de servicios compartidos, se coordinan con los Equipos Scrum como grupo, donde las peticiones fluyen a través de un Product Owner para cada especialidad que las convierte en un backlog transparente y priorizado. Una nota importante es que estos equipos NO son silos de individuos que se sientan juntos (por eso se representan como pentágonos huecos); los miembros de su equipo se sientan en los Equipos Scrum reales, pero componen este Scrum virtual propio con el fin de difundir el backlog y mejorar el proceso.

Nota final

El Scrum@Scale está diseñado para escalar la productividad, para conseguir que toda una organización aporte el doble de valor a la mitad de coste. Implementar un flujo de trabajo racionalizado a un ritmo sostenible con una mejor toma de decisiones mejora el entorno de trabajo, aumenta la agilidad del negocio y genera mayores beneficios para todas las partes interesadas.

Scrum@Scale está diseñado para saturar una organización con Scrum. Un Scrum bien implementado puede hacer funcionar toda una organización con Scrum@Scale como sistema operativo.

Agradecimientos

Historia

El Dr. Jeff Sutherland desarrolló la Scrum@Scale basándose en los principios fundamentales de Scrum, la teoría de los Sistemas Adaptativos Complejos, la teoría de los juegos y su trabajo en biología. La versión original de esta guía fue creada en colaboración con Jessica Larsen, Avi Schneier y Alex Sutherland. Las ediciones posteriores se han perfeccionado con las aportaciones de muchos profesionales experimentados de Scrum, basadas en los resultados de su trabajo de campo.

Personas y organizaciones

Reconocemos a IDX por la creación del Scrum de Scrums que permitió por primera vez que Scrum escalara a cientos de equipos, PatientKeeper para la creación del MetaScrumque permitió el rápido despliegue de un producto innovador, y a OpenView Venture Partners por escalar Scrum a toda la organización. Valoramos las aportaciones de Intel, que nos enseñó que "nada escala excepto una arquitectura sin escala", y de SAP, con la mayor organización de productos de equipos Scrum, que nos enseñó que la participación de la dirección en el MetaScrum es esencial para conseguir que más de 2.000 equipos Scrum trabajen juntos.

Los entrenadores y formadores ágiles que implementan estos conceptos en Amazon, GE, 3M, Toyota, Spotify, Maersk, Comcast, AT&T y muchas otras empresas han sido de gran ayuda a la hora de probar estos conceptos en un amplio abanico de empresas de diferentes ámbitos

 

---

1. "Agilidad empresarial". Wikipedia, Última modificación: 27 de febrero de 2020.  https://en.wikipedia.org/wiki/Business_agility.
2. Johnson, Jim. Nuevo informe CHAOS. El Grupo Standish. 2018.
3. Ogunnaike, Babatunde A. y Ray, W. Harmon. Dinámica de Procesos, Modelado y Control. Oxford University Press. 1994.
4. Hackman, J Richard. Liderando Equipos: Setting the Stage for Great Performances. Harvard Business Press. 2002.
5. Sutherland, Jeff, Coplien, James O., y The Scrum Patterns Group. Un libro de Scrum: El espíritu del juego. Librería Pragmática. 2019.
6. Sutherland, Jeff. "Inventar y reinventar SCRUM en cinco empresas". En el sitio oficial de la alianza ágil. 2001.
7. Sutherland, Jeff. "El futuro de Scrum: La canalización paralela de sprints en proyectos complejos". Actas de la Conferencia de Desarrollo Ágil. IEEE Computer Society 90-102. 2005.
8. Sutherland, Jeff y Altman, Igor. "No tomar prisioneros: Cómo hace Scrum un grupo de capital riesgo". Conferencia Ágil, 2009. AGILE'09, IEEE 350-355. 2009.