Scrum de Scrums: Un punto de partida para escalar a Ágil
Agile 101
Scrum de Scrums: Qué es y qué hace falta
Entender los diferentes enfoques para escalar ágil puede ser abrumador. Al fin y al cabo, a pesar de que Agile se dirigía originalmente a equipos pequeños -lo que incluye el marco de trabajo de Scrum— ha habido bastantes intentos de escalarlo.
En este artículo, cubriremos uno de estos enfoques: scrum de scrums (SoS). Entenderá cómo funciona, conocerá su historia y descubrirá las similitudes y diferencias entre él y otros enfoques.
Breve reseña
El scrum de scrums es una técnica para escalar scrum a grupos más grandes. En pocas palabras, consiste en coordinar el trabajo de varios equipos de scrum que trabajan juntos, creando un equipo de scrum más grande cuyos miembros serán equipos regulares más pequeños.
El éxito de la adopción de scrum de scrums requiere que cada equipo individual sea un equipo de scrum de alto rendimiento. Es decir: no intente hacer scrum en el grande hasta que lo haga con éxito en el pequeño.
El scrum de scrums suele estar «incrustado» en otros enfoques de escalado, sirviendo como punto de partida para esos esfuerzos. Además, la gente a menudo lo mezcla con otros enfoques, en particular scrum a escala, o scrum@scale, como se llama oficialmente. Más adelante en el artículo aprenderá cómo se relacionan los dos enfoques con más detalle.
Breve Historia
Aprender sobre la historia de SoS es aprender sobre la propia historia de scrum. Así que, hagámoslo.
Scrum fue creado originalmente por Jeff Sutherland y Ken Schwaber. Ambos ya estaban experimentando con enfoques que se convertirían en el marco de trabajo a principios de los noventa. Publicaron el enfoque con un artículo en 1996 en OOPSLA, habiéndolo codificado en un taller en la misma conferencia el año anterior.
Al igual que la mayoría de las metodologías bajo el paraguas «ágil», Scrum aboga por equipos pequeños, con no más de 9 personas. El empirismo ha demostrado que los equipos más pequeños rinden más, entre otras razones, por la agilización de la comunicación.
Sin embargo, Sutherland y Schwaber, en algún momento, necesitaron trabajar con una organización más grande. Las experiencias en el escalado de scrum llevaron a Sutherland a escribir un artículo en 2001 en el que formalizaba el Scrum de scrums.
¿Cómo funciona?
En comparación con muchos de los otros enfoques de scrum a escala, el scrum de scrums es increíblemente sencillo. Funciona exactamente como su nombre indica: es un scrum compuesto por scrums más pequeños, que le ayuda a coordinar a un mayor número de personas dividiéndolas en equipos de scrum más pequeños de hasta 10 miembros.
Cada equipo individual nombra a un «embajador» para que participe en la versión escalada del standup diario. Otro nuevo rol es el scrum of scrums master, que es simplemente un scrum master, pero a un nivel superior.
Similitudes y diferencias
A continuación analizaremos las similitudes y diferencias entre el scrum de scrums y los enfoques de la competencia.
Hay muchas similitudes y diferencias que se pueden encontrar. Para empezar, el scrum de los scrums suele estar «incrustado» en otros enfoques para escalar scrum, sirviendo como punto de partida para esos esfuerzos. Además, SoS comparte similitudes con los enfoques ligeros que pretenden dejar scrum lo más intacto posible.
Por otro lado, SoS es dramáticamente diferente de los enfoques que construyen mucho sobre scrum, añadiendo capas, roles y ceremonias adicionales.
Por último, SoS se confunde a menudo con scrum@scale, o «scrum a escala», como también se le llama. Como se verá, se trata de enfoques relacionados pero aún así diferentes.
Scrum de scrums vs LeSS
LeSS significa Scrum a gran escala. Comparte algunas similitudes con SoS y Scrum regular, incluyendo todos los roles y eventos regulares. Resulta que LeSS es uno de los marcos menos prescriptivos que existen, ya que no añade un montón de cosas extra sobre scrum.
Sin embargo, existen importantes diferencias. En realidad, LeSS ofrece dos marcos según el número de personas en la organización:
-
LeSS: Hasta ocho equipos (de hasta ocho personas cada uno).
-
LeSS Enorme: Hasta unos cuantos miles de personas en un producto.
En el pequeño marco de LeSS, hay un único PO, backlog, definición de hecho y sprint para todos. Los equipos siguen siendo equipos interfuncionales, como en scrum normal.
En LeSS Enorme, hay divisiones denominadas «áreas de requisitos», que corresponden a las principales áreas de interés del cliente dentro de un producto. Cada área de requisitos tiene su propio propietario de área de producto y contiene de cuatro a ocho equipos. Todos los equipos trabajan a partir del mismo backlog. Sin embargo, cada elemento se asigna a una única área de requisitos del producto, por lo que cada equipo puede centrarse en su propio trabajo.
Por otro lado, el Scrum de scrums aborda el problema de la escalabilidad adicional adoptando la misma estructura a un nivel superior. En otras palabras, se puede tener un scrum de scrums de scrums, para coordinar múltiples scrums de scrums. Los roles y eventos también se escalan a este nivel: se tiene una reunión diaria de scrum de scrums, y un scrum de scrum de scrum master.
Scrum de Scrums vs SAFe
SAFe (Scaled Agile Framework) was first introduced in 2011 and since then has gone through five major updates.
S SAFe (Marco Ágil Escalado, del inglés Scaled Agile Framework) se introdujo por primera vez en 2011 y desde entonces ha pasado por cinco grandes actualizaciones.
SAFe está dirigido a la empresa, y tiene como objetivo apoyar a un gran número de personas, en situaciones que requieren un control más estricto. Así, SAFe introduce muchos artefactos, roles y eventos nuevos, lo que lo convierte en uno de los marcos más complejos y prescriptivos que existen.
Por otro lado, SoS es una evolución natural de scrum, que conecta un número relativamente pequeño de equipos regulares de scrum.
Más información sobre el Marco Ágil Escalado aquí.
Scrum de Scrums vs Scrum@Scale
Por último, pero no menos importante, comparemos el scrum de scrums y el scrum a escala.
Para empezar, Scrum de scrums es mucho más antiguo: se formalizó por primera vez en un artículo de 2001 de Sutherland, pero él y Schwabber ya habían utilizado el enfoque a escala.
Img Src: scruminc.com
Scrum@scale es una empresa más reciente, lanzada en 2018 -a pesar de haberse trabajado ya en 2014- como una asociación entre Sutherland y Scrum, Inc (sin la participación de Schwaber, que tiene otro marco, Nexus, para escalar scrum).
Scrum a escala es un marco relativamente ligero, especialmente cuando se compara con pesos pesados como SAFe. Sin embargo, tiene objetivos ambiciosos, ya que intenta reducir el tiempo de toma de decisiones en toda la organización. Scrum of scrums, por otro lado, sólo intenta coordinar un número de equipos de scrum.
¿Por qué hay tanta confusión entre estos dos enfoques? Para empezar, Jeff Sutherland está involucrado en la creación de ambos. Además, la denominación es algo confusa, por lo que es comprensible que la gente piense que son sinónimos.
Por último, hay otra fuerte relación en juego entre los dos enfoques. Y es el hecho de que scrum a escala utiliza scrum de scrums para escalar y coordinar los equipos de scrum que trabajan en el incremento. A continuación, añade unos cuantos roles nuevos por encima, incluidos los que aportan agilidad a la parte de gestión de la organización.
Funciones y responsabilidades clave
El scrum de scrums es exactamente lo que su nombre sugiere: un scrum compuesto por otros más pequeños. Esto significa que presenta los mismos roles que el scrum normal.
Sin embargo, hay algunos roles adicionales. Para empezar, cada equipo interno tiene un representante que asiste a las reuniones del scrum de scrum. Y existe una versión «escalada» del scrum master, llamada scrum de scrums master.
El scrum de scrums tiene su propio backlog para hacer un seguimiento de los impedimentos para la correcta colaboración entre equipos.
Reuniones clave, ciclos, cadencias de entrega
Si SoS presenta los mismos roles que el scrum regular, también presenta los mismos eventos.
Además de los eventos regulares, SoS se basa en una versión escalada de la reunión diaria o scrum diario. Un representante o embajador de cada equipo asiste a este evento, en el que los equipos pueden coordinarse y asegurarse de que se eliminan los impedimentos a su colaboración.
El scrum escalado sigue prácticamente el mismo orden del día que una reunión de scrum normal. Cada participante responde a las mismas preguntas:
-
¿Qué hizo ayer su equipo para alcanzar el objetivo del sprint?
-
Qué hará su equipo hoy para avanzar hacia el objetivo del sprint?
-
¿Hay algún impedimento para lograr el objetivo del sprint?
Sin embargo, hay una diferencia importante entre las versiones regulares y escaladas de la reunión de scrum. Normalmente, no se utiliza la diaria para resolver problemas; sólo se quiere conocer los problemas, pero se supone que se abordan más tarde.
Por otro lado, está bien resolver problemas durante la versión escalada, ya que afectan a otros equipos y a la colaboración entre ellos. Por lo tanto, tiene sentido programar esta reunión con una duración mayor que la del scrum regular.
Además, a pesar de que se recomienda celebrar las reuniones del scrum de scrum a diario, hay equipos que informan de su éxito celebrándolas con menos frecuencia, de 2 a 4 veces por semana, por ejemplo.
Errores comunes
A diferencia de otros intentos de escalar scrum SoS no es un marco de trabajo pesado por sí mismo. En cambio, es un enfoque ligero compuesto por algunos scrums regulares más pequeños.
Esto tiene pros y contras. El lado positivo es que, como no añade muchos artefactos nuevos a scrum, no es tan difícil empezar a usarlo, al menos para los equipos que ya están haciendo scrum con éxito en los pequeños.
Por otro lado, también significa que el scrum de los scrums es susceptible a la mayoría de los errores comunes de scrum regular:
-
Utilizar la reunión de scrum como una reunión de estado
-
No realizar la reunión del scrum de scrums con la frecuencia que debería
-
No hacer un seguimiento de los problemas e impedimentos mencionados en la reunión
Cómo empezar
Como se mencionó, comenzar con scrum de scrums puede ser más fácil que otros enfoques para escalar scrum, ya que no agrega un montón de capas y roles adicionales sobre el marco original. Aquí hay algunos consejos para empezar:
- Formar a todo el mundo en el tema para que se pongan de acuerdo.
- Formar a todos en las habilidades para sus funciones y responsabilidades.
- Si es necesario, capacite a todos en scrum regular, incluyendo la guía de scrum y la capacitación especializada.
- Comience por asegurarse de que scrum está implementado y funcionando de manera saludable a nivel de equipo individual primero, antes de intentar cualquier escalamiento.
- Cuando llegue el momento de escalar, asegúrese de obtener la aprobación de las personas clave de la organización, y también de cada equipo de scrum individual.
Más información
-
Artículo original del Dr. Jeff Sutherland: Ágil puede escalar: Inventando y reinventando SCRUM en cinco empresasArtículo original del Dr. Jeff Sutherland: Ágil puede escalar: Inventando y reinventando SCRUM en cinco empresas
-
Guía de ScrumGuía de Scrum
-
Qué es la metodología Scrum y la gestión de proyectos ScrumQué es la metodología Scrum y la gestión de proyectos Scrum
-
Scrum a gran escala: Visión general de LeSSScrum a gran escala: Visión general de LeSS
Crecer sin dolor, con Scrum de Scrums
El marco original de scrum estaba pensado para un único y pequeño equipo. Sin embargo, las empresas suelen tener más equipos y aparece la necesidad de conectarlos y coordinarlos.
Creado por el propio cofundador de scrum, scrum of scrums es uno de los muchos enfoques para escalar scrum. A diferencia de muchos de los enfoques competidores, SoS es una extensión natural del marco original.
Entre sus características, destaca el hecho de que scrum of scrums suele estar integrado en otros marcos más complejos y pesados. Eso sirve como testimonio de su eficacia.
Signup for updates!
[wpforms id=»8824″]
As a software development manager you just inherited a large codebase and everyone is expecting you to come up with crucial new features.
Preferably yesterday.
You’d love to do it. But neither you nor your team understands the code. Could code refactoring help you? Code refactoring in agile is hot after all. You hear it’s what keeps teams able to respond to change quickly.
And that’s exactly what you need.
But neither you nor your team have experience with it. You’re looking to get a good start, to understand the fundamentals and receive guidance on how to practice it.
Well, you’re in the right place.
This article will equip you with the right basics, so you’ll soon be well on your way refactoring the existing code base and adding new features.
¡La vida es buena cuando sus equipos ágiles están sincronizados!
Solicite una demostración personalizada de SwiftEnterprise.
