El equipo de Scrum debe consistir en hasta diez personas. Pero, ¿qué hacer cuando un grupo más grande de especialistas necesita trabajar en un proyecto? ¿O si la organización decide seguir una forma ágil de gestión? Para resolver este problema, los desarrolladores de Scrum propusieron Scrum@Scale. Es una arquitectura sin escala para organizar equipos completos de acuerdo con los principios de Scrum.
Tan pronto como una organización crece, aparecen nuevos tipos de problemas. Por ejemplo, una caída en la efectividad de los empleados que es causada por una estructura interna compleja, una toma de decisiones difícil o la fijación de dirección. Las empresas que operan de manera ágil a nivel de pequeños equipos de proyecto a menudo buscan escalar.
Muchas empresas funcionan bien sin escalar Scrum. Incluso si muchos Equipos de Scrum están funcionando simultáneamente, no necesitan coordinación ya que los grupos operan de manera independiente. Sin embargo, esto no significa que sea un Scrum de múltiples equipos. La necesidad de escalar surge solo cuando la mayor parte de la organización está trabajando en un producto y puede sincronizar sus múltiples Equipos de Scrum de manera efectiva.
La mayoría de las organizaciones que adoptan métodos de gestión ágil a gran escala eligen el modelo SAFE, o Scaled Agile Framework. Hoy, sin embargo, no nos centraremos en SAFE, sino que discutiremos un modelo diferente llamado Scrum@Scale, ya que según el 15º Informe sobre el Estado de Agile de 2021, es la segunda mejor opción entre las empresas que optan por lo ágil.
En 1996, los creadores de Scrum, Jeff Sutherland y Ken Schwaber, estaban trabajando en un gran proyecto. Mientras lo hacían, tenían problemas para mantener a los equipos más pequeños trabajando en Scrum sincronizados. Se les ocurrió una forma de escalarlo, que eventualmente llamaron Scrum@Scale.
Análogo a la Guía oficial de Scrum estaba la Guía Scrum@Scale, que define esta forma de escalar el trabajo como:
Un marco dentro del cual redes de Equipos de Scrum operan siguiendo la Guía de Scrum para resolver problemas complejos adaptativos y entregar productos creativamente con el mayor valor posible.
La premisa básica de Scrum@Scale es la simplicidad y la eficiencia. Por lo tanto, su funcionamiento se basa en una arquitectura sin escala. En otras palabras, utiliza Scrum para escalar Scrum. De esta manera, un equipo de Scrum compuesto por individuos que actúan como Product Owner, Scrum Master o Desarrollador se convierte en el Scrum de Scrums: un equipo compuesto por equipos.
El Scrum de Scrums es un equipo de Scrum con personas que ocupan roles tradicionales de Scrum. Sin embargo, dado que la tarea del Scrum de Scrums es integrar los resultados del trabajo de varios Equipos de Scrum, necesita puestos adicionales:
Se reúnen en los mismos Eventos de Scrum y utilizan Artefactos similares.
La arquitectura sin escala de Scrum@Scale significa que permite escalar más de una vez. Si una organización necesita coordinar equipos a una escala aún mayor, puede establecer un Scrum de Scrums.
Sin embargo, escalar Scrum, como cualquier otra metodología de gestión, tiene sus defectos, y en este caso, son similares a los de los Equipos de Scrum básicos, solo que son proporcionalmente mayores. Por eso recomendamos trabajar los detalles de la colaboración dentro de cada Equipo de Scrum antes de comenzar Scrum a mayor escala. Sugerimos escalar Scrum para equipos experimentados que tengan un buen conocimiento y comprensión de los valores y el funcionamiento de Scrum.
Escalar Scrum no es un juego de niños. Requiere que los Equipos de Scrum apliquen proficientemente los principios de Scrum y sincronicen sus tareas con otros Equipos de Scrum. Por lo tanto, la pregunta básica a responder es: ¿Es necesario escalar? Solo porque haya muchos Equipos de Scrum en una organización no significa automáticamente que coordinarlos traerá mejores resultados.
Si una organización elige aumentar Scrum, obtiene una arquitectura sin escala que puede ser aumentada con éxito aún más. Sin embargo, cada aumento viene acompañado de un incremento en el nivel de complejidad que el Equipo de Product Owners, el Chief Product Owner y el Scrum de Scrums Master deben manejar.
Si te gusta nuestro contenido, únete a nuestra comunidad de abejas trabajadoras en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Como Gerente de Proyectos, Caroline es experta en encontrar nuevos métodos para diseñar los mejores flujos de trabajo y optimizar procesos. Sus habilidades organizativas y su capacidad para trabajar bajo presión de tiempo la convierten en la mejor persona para hacer realidad proyectos complicados.
¿Eres un freelancer que busca formas de promocionar su portafolio? Hoy en día, no solo…
La gestión financiera digital y la contabilidad en línea se han vuelto cada vez más…
Los estatutos del proyecto son el pan y la mantequilla de la gestión de proyectos.…
Las organizaciones de diversas industrias establecen relaciones con posibles empleados, proveedores y socios todos los…
Hay más que suficientes técnicas de gestión por ahí. Algunas parecen intrincadas, mientras que otras…
¿Sabes cómo empezar una ONG? ¿Has estado pensando en ello? ¿Eres consciente de lo que…