LeSS: el framework Large-Scale Scrum explicado

Toda organización que supera a un solo equipo Scrum acaba haciéndose la misma pregunta: ¿cómo se coordinan diez, treinta u ochenta equipos sin perder lo que hizo funcionar a Scrum en primer lugar? SAFe responde añadiendo estructura: más roles, más ceremonias, más capas para mantener a todos alineados. Large-Scale Scrum (LeSS) responde haciendo lo contrario.

LeSS es Scrum aplicado a muchos equipos que construyen juntos un único producto, y lo logra simplificando la organización en lugar de superponerle algo nuevo. En vez de preguntar cómo hacer agile a escala, parte de una pregunta más pequeña y más difícil: cuán simple puede llegar a ser la organización sin dejar de ser genuinamente ágil.

Key Facts

• Large-Scale Scrum fue moldeado por Craig Larman y Bas Vodde, quienes trabajan juntos en el escalamiento de Scrum desde 2005.
• less.works define dos frameworks: LeSS para 2 a 8 equipos y LeSS Huge para más de 8, y describe el límite de ocho equipos como "solo una observación empírica del límite superior", no como una regla rígida.
• less.works nombra diez principios de LeSS, no nueve, una cifra que varios resúmenes de segunda mano entregan de forma errónea.
• En LeSS Huge, un Requirement Area agrupa de 4 a 8 equipos por diseño, nunca menos.

Qué es LeSS (Large-Scale Scrum)

Large-Scale Scrum (LeSS) es Scrum aplicado a varios equipos que construyen juntos un único producto, y lo logra simplificando la organización en lugar de añadirle una capa de coordinación encima. Mientras que muchos frameworks de escalamiento preguntan cómo hacer agile a escala, less.works plantea la pregunta de LeSS de otra manera: cómo podemos simplificar la organización y ser ágiles, en lugar de limitarnos a ejecutar los movimientos.

Craig Larman y Bas Vodde construyeron el framework a partir de trabajo con clientes que comenzó en 2005. Años de escalar Scrum con organizaciones reales se convirtieron en las reglas de LeSS que el framework publica hoy. De ese trabajo surgieron dos frameworks. LeSS cubre de 2 a 8 equipos. LeSS Huge toma el relevo a partir de ahí, para más de 8. less.works es transparente en que el límite de ocho equipos no es una regla rígida, y lo llama "solo una observación empírica del límite superior", el punto en el que han visto que la estructura más pequeña empieza a necesitar ayuda, no un número incorporado a la lógica del framework.

Ambos frameworks mantienen los mismos elementos innegociables: un Product Backlog, una Definition of Done, un Sprint, un Product Owner y un Product Increment potencialmente entregable, sin importar cuántos equipos contribuyan a él.

Los diez principios de LeSS

less.works es explícito sobre la cifra: diez principios, no nueve. Eso confunde a la gente porque bastantes resúmenes de segunda mano la redondean a nueve y omiten uno por el camino. La distinción importa menos como dato curioso y más porque estas son las ideas de las que realmente provienen las reglas de LeSS. less.works dice que los principios "nos guiaron al crear LeSS" y que deben guiar una implementación del mismo modo: son a lo que se recurre cuando aparece una situación que las reglas no cubren.

Vale la pena detenerse en ese último principio si ha pasado tiempo en SAFe o en otro framework que se apoya en flujos de trabajo paralelos: la teoría de colas indica que añadir más trabajo en curso ralentiza todo, aunque parezca que más esfuerzo en paralelo debería acelerar las cosas. LeSS aplica esa lógica a toda la organización, no solo al tablero de un equipo.

LeSS frente a LeSS Huge: qué cambia realmente a partir de ocho equipos

Entre dos y ocho equipos es donde vive LeSS, y dentro de ese rango nada cambia estructuralmente en la coordinación: un Product Backlog, un Product Owner que trabaja directamente con cada equipo, un Sprint. Pasados los ocho equipos, LeSS Huge añade la maquinaria necesaria para mantener una visión del producto completo cuando ningún Product Owner puede razonablemente seguir por sí solo el trabajo diario de cada equipo.

Los Area Product Owners se especializan en su área y actúan como Product Owners frente a los equipos que la integran, pero el Product Owner general conserva la decisión final sobre el backlog y la visión de todo el producto. Ambos se sincronizan constantemente, en especial antes del Sprint Planning, para que las prioridades locales de un Area PO nunca se alejen demasiado de lo que el Product Owner general ha decidido que es más importante. Ese punto de coordinación es donde LeSS Huge justifica su complejidad adicional: existe para proteger el enfoque en el producto completo cuando el número de equipos supera lo que una sola persona puede seguir.

El Sprint de LeSS: un Sprint, muchos equipos

Conceptualmente, LeSS ejecuta un Sprint a nivel de producto para todo el producto, no un Sprint por equipo con su propio reloj. Todos los equipos empiezan y terminan juntos, y el resultado es un Increment integrado y potencialmente entregable, no un montón de incrementos por equipo que alguien deba conciliar después. El Sprint Planning de todos los equipos ocurre al mismo tiempo, y lo mismo sucede con el Sprint Review y la retrospectiva. Lo que no necesita coincidir es el refinamiento del backlog: los equipos pueden refinar según su propio calendario, siempre que los elementos estén listos cuando comience el Sprint Planning.

El propio Sprint Planning se divide en dos partes, igual que a nivel de un solo equipo, solo que con más personas en la sala durante la primera mitad.

El refinamiento es donde LeSS exige más disciplina, ya que es fácil dejarlo pasar cuando nada lo obliga a entrar en el calendario como sí ocurre con el Sprint Planning. less.works llama a la versión multiequipo "posiblemente el evento más importante de LeSS", y los equipos suelen dedicarle aproximadamente una décima parte de la capacidad de su Sprint. Si se omite, el Sprint Planning One se convierte en una reunión dedicada a aclarar en lugar de seleccionar, que es lo opuesto a su propósito.

El Sprint Review merece una mención aparte, porque es fácil ejecutarlo como una demo de un solo equipo estirada a más personas. LeSS lo trata como un genuino punto de inspección y adaptación sobre todo el producto, no como una puerta de aprobación del Product Owner, una distinción más sutil de lo que parece. Una demo que en realidad es un punto de control de aprobación entrena a los equipos para actuar de cara al PO. Un bazar que deja a las partes interesadas pasear, hacer preguntas y dar forma a lo que viene entrena a la organización a mirar realmente el producto que construyó.

Un Product Owner para todo el producto (la parte que todos ponen en duda)

Este es el detalle que deja atónita a la mayoría de las personas la primera vez que lo oyen: un Product Owner, para todo el producto, en todos los equipos, sin importar cuántos equipos sean. Suena a un cuello de botella a punto de ocurrir. En la práctica, LeSS hace que las cuentas funcionen siendo preciso sobre lo que el Product Owner realmente tiene que hacer.

Eso deja al Product Owner completamente fuera del Sprint Planning Two, de los Daily Scrums y de las retrospectivas de cada equipo. Esas reuniones pertenecen a los equipos, no al PO. LeSS lo consigue separando dos tareas que muchas organizaciones agrupan en un solo rol: la priorización y la aclaración. El Product Owner es dueño de la priorización, de decidir qué importa más y por qué. La aclaración, el ir y venir sobre cómo exactamente debe comportarse un elemento, ocurre directamente entre el equipo y el cliente o la parte interesada, con el PO disponible pero sin ser necesario como intermediario. less.works describe el rol previsto como "un conector, no un intermediario", un trabajo significativamente distinto de ser el único canal aprobado para cada pregunta que tenga un equipo.

También es una forma distinta de la que muchos lectores suponen al llegar. No se trata de un Product Manager sentado por encima de varios Product Owners, coordinando un equipo de coordinadores. Es una persona que hace el trabajo del Product Owner de Scrum, a escala de producto, con las partes del trabajo que no escalan delegadas en los equipos.

Esa división también protege la autonomía de los equipos de una manera fácil de pasar por alto. Si cada pregunta aclaratoria tuviera que pasar por una sola persona, LeSS recrearía exactamente el cuello de botella que sus críticos suponen que tiene. En cambio, los equipos que pueden hablar directamente con los clientes avanzan más rápido en los detalles, y el Product Owner dedica el tiempo liberado a lo único que solo una persona puede hacer por todo el producto: decidir qué se construye a continuación. Si está comparando este rol con el trabajo de coordinación que realiza un Scrum Master a nivel de equipo, la división es la misma que ya existe en el Scrum de un solo equipo, solo que aplicada entre más equipos en lugar de dentro de uno.

LeSS frente a SAFe: descaling frente a añadir estructura

Los lectores llegan a esta página normalmente después de haber leído sobre SAFe, y la forma justa de compararlos es decir qué optimiza realmente cada uno. SAFe mantiene a los equipos más o menos como están y añade capas, roles y una cadencia de planificación escalada para coordinarlos. LeSS va en la dirección contraria: le pide a la organización que se reorganice en torno a equipos de funcionalidad (feature teams), que elimine roles adicionales y que se coordine mediante un Sprint y un Backlog en lugar de una pila de eventos de planificación.

Ningún lado de esa tabla está equivocado, y ninguno de los frameworks es más ágil que el otro según alguna medida objetiva. Resuelven el mismo problema de coordinación con instintos opuestos: SAFe supone que la coordinación necesita más andamiaje, y LeSS supone que la mayor parte de ese andamiaje es el problema que intenta resolver. Donde SAFe usa el PI Planning como evento de sincronización, LeSS usa el Sprint Planning One, el mismo evento que un solo equipo ya ejecuta, solo que con todos los equipos en la sala. Esa es la brecha filosófica en una sola comparación: un framework creó un evento nuevo para manejar la escala, el otro escaló el evento que ya tenía.

LeSS frente al modelo Spotify frente a Scrum multiequipo simple

Dos comparaciones más surgen con la frecuencia suficiente para tratarlas brevemente. Ninguna es realmente una competidora de LeSS como lo es SAFe, ya que resuelven problemas ligeramente distintos.

El modelo Spotify nunca estuvo pensado para copiarse por completo, y la propia Spotify superó la estructura original hace años. Funciona bien como vocabulario (squads, chapters, guilds) pero mal como reglamento, porque nunca publicó uno. El Scrum multiequipo simple, varios equipos que aplican cada uno Scrum estándar sin un framework compartido por encima, es lo que la mayoría de las organizaciones hace por defecto antes de adoptar otra cosa, y suele ser lo primero que se rompe: nada impide que los Product Owners de dos equipos prioricen en direcciones opuestas, porque nada vincula sus backlogs en primer lugar. LeSS es, en un sentido real, lo que se obtiene al tomar esa configuración por defecto y corregir lo específico que la rompe: un Backlog, un dueño, un Sprint. Existe una respuesta más antigua a la misma pregunta que vale la pena conocer: Crystal escala cambiando a un miembro más pesado de una familia de metodologías a medida que el equipo crece, en lugar de mantener un solo framework y remodelar la organización en torno a él.

La realidad de la adopción: qué exige realmente adoptar LeSS

SAFe se vende con más facilidad, y vale la pena explicar con claridad por qué. Un despliegue de SAFe añade cosas: nuevos roles, un plan de capacitación, certificaciones, un evento con nombre en el calendario. Parece progreso en un organigrama, incluso antes de haber entregado nada. Una adopción de LeSS elimina cosas, y eliminar es una historia mucho más difícil de contar a una sala llena de gerentes cuyo trabajo actual podría ser una de las cosas que desaparecen.

Nada de eso es sutil. Reorganizarse en torno a feature teams suele significar que el trabajo de algunas personas cambia de forma, y consolidar la propiedad del producto en un solo rol suele significar que los cargos de otras personas desaparecen o se redefinen. Es una exigencia genuinamente distinta a la de SAFe, que en su mayor parte capacita a las personas para nuevos roles en lugar de eliminar roles que ya existen. También es parte de la razón por la que las adopciones de LeSS tienden a ser más pequeñas y a extenderse más despacio que los despliegues de SAFe. Pocas organizaciones están dispuestas a tener esa conversación con su propia estructura de gestión, incluso cuando el argumento de fondo a favor del descaling es sólido.

LeSS tiende a convenir a las organizaciones que ya aplican bien el Scrum de un solo equipo y tienen un backlog real que lo demuestre, no a las que todavía están aprendiendo qué significan en el día a día un Sprint o una Definition of Done. También conviene a las organizaciones dispuestas a nombrar a un Product Owner con autoridad real sobre todo el producto, y dispuestas a reorganizarse en torno a feature teams en lugar de defender la estructura de equipos por componente que ya tienen. No conviene a las organizaciones que necesitan la estructura de reportes y de roles que exige un entorno regulado o fuertemente contractual, ni a las que gestionan varios productos genuinamente separados que no comparten un backlog desde el principio. Esos casos suelen encajar mejor en la capa de portafolio de SAFe o en un modelo completamente distinto.

Cuándo no usar LeSS

Ninguna de estas es una razón por la que LeSS sea un mal framework. Son razones por las que una organización específica, en un momento específico, podría no estar lista para lo que exige. La versión honesta de esa frase también se aplica a SAFe o a cualquier enfoque de escalamiento: el framework no es la parte difícil. Lo difícil es cambiar la forma en que una organización está realmente estructurada, y eso es cierto ya sea que el framework añada andamiaje o lo retire.

LeSS no es la venta más fácil, y nunca intentó serlo. Si su organización ya aplica bien el Scrum de un solo equipo y está dispuesta a reorganizarse en torno a feature teams y a un único Product Owner, el descaling es una opción real, no solo una postura filosófica. Si aún no está dispuesta a hacerlo, SAFe o un enfoque de toque más ligero probablemente llegará más lejos y más rápido, y esa también es una respuesta legítima. La elección no consiste en cuál framework es más ágil. Consiste en qué dirección de cambio puede realmente emprender su organización.