5 marcos de escalamiento ágiles comparados: ¿cuál debería usar?

Imagínese esto: al comienzo de un proyecto, reúne un equipo único, eficaz y multifuncional de personas comprometidas con el logro de los objetivos del producto. Para mejorar el rendimiento, asegúrese de que el equipo sea competente en Agile. Crece la demanda del producto, aumentando los requerimientos y ampliando la cartera. Usted y otras partes interesadas se dan cuenta de que es necesario escalar el equipo. ¿Suena familiar?

El escalado permite que varios equipos trabajen juntos para mantener su agilidad. Si hay más trabajo por hacer del que su equipo puede manejar en un período de tiempo razonable, es hora de escalar. Sin embargo, para hacerlo, debe seleccionar el marco correcto, y hay varios para elegir. Elija mal y la implementación podría fallar, interrumpiendo la productividad y teniendo importantes repercusiones financieras.

El marco que mejor se adapte a su equipo variará en función de factores como la financiación disponible, el enfoque organizativo y la complejidad del producto.

¿Cuándo debe escalar?

Hay una serie de criterios clave que debe cumplir antes de considerar escalar:

¿Se puede gestionar el desarrollo con un solo equipo?

La implementación de marcos ágiles escalados puede ser compleja y llevar mucho tiempo, así que no escale si no es necesario. Cuando la carga de trabajo de su equipo supera sus capacidades, es necesario escalar.

¿Tu equipo es ágil?

Quizás el criterio más importante sea la competencia de su equipo en los enfoques ágiles. Si su equipo no tiene experiencia en Agile, escalar creará más problemas.

¿Las prácticas de desarrollo de su equipo necesitan mejorar?

Si las prácticas de ingeniería de su equipo no son eficientes, es posible que el escalado no produzca los resultados deseados. Prácticas como la implementación adecuada de DevOps y una canalización de CI/CD son vitales para la coherencia entre los equipos. Además, sin un control de calidad estandarizado, puede ser difícil probar nuevas funciones.

¿Su equipo ofrece incrementos integrados?

El escalado implica la integración de múltiples equipos que colaboran en el mismo producto, donde cada equipo produce funciones que funcionan juntas. En la siguiente tabla se detallan las cuatro posibles configuraciones de equipos y productos. Tenga en cuenta que solo uno necesita escalado.

Elegir un marco de escala

Hay numerosos marcos de escalamiento Agile para elegir, pero nos centraremos en cinco de las soluciones más utilizadas: Scaled Agile Framework (SAFe), Nexus, Large-Scale Scrum (LeSS), Scrum@Scale y Disciplined Agile (DA) . He encontrado que estos son los marcos más efectivos y se pueden aplicar a una variedad de escenarios y organizaciones. Las siguientes secciones lo equiparán con la información que necesita para tomar la mejor decisión para su contexto de escalado único.

1. Marco ágil escalado (SAFe)

SAFe es el marco más popular para el escalado ágil. Una encuesta de 2021 encontró que el 37 % de los practicantes de Agile lo usan, en gran parte debido a sus múltiples configuraciones, todas las cuales se enfocan en flujos de valor y tienen guías y procedimientos bien definidos.

Como SAFe se utiliza para ofrecer soluciones complejas que requieren más de 50 personas, organiza equipos en trenes de lanzamiento ágiles (ART). Para sincronizar los equipos en un ART, SAFe utiliza iteraciones de incremento de programa, similares a los sprints de Scrum, y cada iteración suele durar de ocho a 12 semanas. Este enfoque permite a los gerentes de productos mantenerse enfocados en los objetivos generales y supervisar una hoja de ruta de productos compleja de manera eficiente sin introducir cambios excesivos.

SAFe se basa en el marco Scrum pero con un par de diferencias clave: la adopción de SAFe ocurre a nivel empresarial en lugar de a nivel de equipo; y mientras Scrum otorga al propietario del producto la autoridad exclusiva sobre la priorización, SAFe fomenta un enfoque más democrático.

SAFe tiene cuatro niveles de implementación:

Seguridad esencial

Essential SAFe es la base de SAFe y debe dominarse antes de pasar a cualquiera de las configuraciones posteriores. Utiliza roles de Scrum establecidos, como maestro de Scrum, gerente de producto y propietario del producto, y también presenta un nuevo rol: ingeniero de capacitación de lanzamiento. Esta persona actúa como líder-servidor y entrenador de ART, guiando a los equipos para alinear sus objetivos. Puede haber entre cinco y 12 equipos en un ART, y cada ART puede ofrecer una solución completa.

Solución grande

Esta configuración se asienta sobre Essential SAFe e introduce un concepto llamado "tren de soluciones". Se utiliza cuando se crean soluciones grandes y complejas que requieren la coordinación de múltiples ART (potencialmente cientos o incluso miles de personas) que trabajan en el mismo flujo de valor. Por ejemplo, si trabaja en Microsoft y tiene tres equipos separados que programan Excel, Word y PowerPoint, todos contribuyen al mismo flujo de valor: Microsoft Office.

portafolio

La cartera consta de múltiples ART que trabajan en diferentes flujos de valor. Continuando con el ejemplo de Microsoft: equipos separados que trabajan en los productos Office, Skype o Xbox de la empresa.

seguridad completa

Esta configuración combina todas las capas (esencial, gran solución y cartera) para coordinar la gestión del equipo en toda la empresa.

2. Nexo

El marco Nexus también se basa en Scrum, pero es más liviano que SAFe y solo requiere pequeños ajustes que facilitan la colaboración entre tres a nueve equipos. La implementación de Nexus no requiere roles adicionales. Más bien, un representante de cada equipo se une a un equipo de integración central que alinea el trabajo hacia un solo objetivo. De manera similar a Scrum, todos los equipos se reúnen para una sesión de planificación de sprint, cuyos resultados forman la acumulación de productos compartida. Para verificar el progreso, cada equipo realiza una reunión diaria similar a un stand-up, y el equipo de integración también se reúne para informar el progreso de su equipo.

Durante un sprint, los equipos participan en una sesión de refinamiento para priorizar y estimar la acumulación. Debido a que la complejidad de la gestión del trabajo pendiente aumenta con la cantidad de equipos, Nexus exige sesiones de refinamiento. Los equipos se reúnen para revisiones y retrospectivas después de cada sprint.

3. Scrum a gran escala (LeSS)

LeSS es casi idéntico a Nexus, pero tiene diferencias menores, como convenciones de nombres y sesiones adicionales de planificación de sprints específicas del equipo. También se diferencia en su capacidad de ampliación con su segunda configuración, LeSS Huge, que admite la colaboración de más de ocho equipos.

LeSS Huge adopta un enfoque centrado en el cliente para organizar el desarrollo. Para administrar el trabajo de manera efectiva, se requiere que el propietario del producto divida la acumulación de productos de alto nivel en "atrasos de área" más pequeños de elementos más granulares y luego los clasifique aún más, en áreas de requisitos.

Estas áreas de requisitos están gestionadas por propietarios de productos de área (APO). Los APO se especializan en los campos relacionados con cada área y trabajan con varios equipos en soluciones para su área. Cada requisito almacenado en el backlog pertenece solo a un área de requisitos, y cada área es administrada por un solo APO. Juntos, el propietario del producto y los APO forman un equipo responsable de priorizar con una visión de todo el producto.

4. Scrum@Escala

Scrum@Scale es una extensión de Scrum y probablemente el marco más fácil de aprender y comprender. Escala de un equipo a un equipo de equipos.

Un componente central del marco es Scrum of Scrums (SoS). Cada equipo elige a una persona para que los represente en las reuniones de SoS, que generalmente se llevan a cabo todos los días después de las reuniones de los equipos individuales. El objetivo de la reunión de SoS de cada día es ayudar a la coordinación y la comunicación entre los equipos, y facilitar la gestión sencilla de cualquier dependencia o superposición.

Los roles únicos dentro de este marco incluyen el maestro SoS, esencialmente una versión escalada de un maestro Scrum, y el propietario principal del producto, que trabaja con los propietarios del producto del equipo para formar una acumulación conjunta para el SoS.

Scrum@Scale es menos prescriptivo que otros marcos, lo que permite a las organizaciones escalar a su propio ritmo. Si la cantidad de equipos continúa creciendo y las reuniones de SoS se vuelven demasiado grandes, las organizaciones pueden escalar el marco a un Scrum de Scrum de Scrums (SoSoS).

5. Disciplinado Ágil (DA)

DA se diferencia de los otros marcos en que actúa más como una caja de herramientas desde la cual puede elegir las estrategias de escalamiento más apropiadas, en lugar de un marco rígido con reglas que debe obedecer. Es un híbrido basado en el contexto de varios marcos, incluidos Scrum y Kanban, que se puede adaptar a las necesidades de cada proyecto, centrado en el principio "La elección es buena". DA se basa en la idea de que cada equipo y organización es único en su tamaño, distribución y dominio, y cada miembro del equipo también es único, con sus propias habilidades y experiencias.

Se puede aplicar a nivel de equipo de desarrollo de software o en toda la empresa. Para este último, el kit de herramientas DA identifica lo que deben abordar diversas funciones comerciales, como finanzas, operaciones de TI y gestión de proveedores, y presenta una variedad de opciones para hacerlo.

DA distingue tres fases del proyecto: Inicio, Construcción y Transición, y cada una comprende objetivos de proceso orientados a la entrega. Debido a que este marco se enfoca en el ciclo de vida de entrega completo, a diferencia de solo la compilación, presenta más roles que los otros marcos. Los roles principales, que se encuentran en cada equipo de DA, son parte interesada, miembro del equipo, líder del equipo, propietario del producto y propietario de la arquitectura. También hay cinco roles de apoyo, que a menudo se usan de forma temporal para ayudar a escalar: especialista, experto en el dominio, experto técnico, probador independiente e integrador.

DA se puede usar encima de los otros marcos para escalar aún más.

Elija con cuidado y escale lentamente

Escalar equipos ágiles e integrar su trabajo sin problemas es difícil, pero se puede hacer más fácil seleccionando el mejor marco. Utilice el siguiente diagrama de flujo como primer paso para guiar su proceso de toma de decisiones.

Estoy seguro de que encontrará el marco de escala que se adapte a la experiencia, el enfoque, el presupuesto y los productos de su organización entre los que se presentan aquí. Cualquiera que sea el marco que elija, es vital no apresurarse: escale gradualmente para minimizar las interrupciones y planifique los cambios con mucha anticipación.

¿Ha utilizado estos marcos en alguna de sus actividades de escalado? Cuéntanos tus experiencias en la sección de comentarios.