Scrum a gran escala: Visión general de LeSS

Large Scail Scrum 1

Agile 101

  • Cross-team collaboration as needed on architecture, design, modeling, etc.
  • Use the source code as a fountain of knowledge about the product.
  • Use Open Space “technology” to share information, knowledge, and experience.
  • Promote cross-team interactions through observing each other’s Daily Scrums and simply sitting having one or more members sit with another team (Travelers).
  • Form self-organized Communities of Practice (CoP) of volunteers with a shared interest. Support the informal leaders, CoP coordinators, that naturally rise in the group because of their more than average interest in the topic.
  • Form self-organized Communities of Practice (CoP) of volunteers with a shared interest. Support the informal leaders, CoP coordinators, that naturally rise in the group because of their more than average interest in the topic.

Introducción a Scrum a gran escala (LeSS)

Large Scrum, LeSS para abreviar, ha captado su atención. Tal vez usted acaba de comenzar con Scrum, pero ya está pensando en los próximos pasos. Tal vez usted es un veterano de Scrum de un solo equipo, buscando ampliarlo a otros equipos.

O tal vez usted ya tiene varios equipos siguiendo Scrum y está experimentando algunos de los desafíos de la coordinación de varios equipos que trabajan en un solo producto.

De cualquier manera, usted quiere saber más acerca de Scrum a gran escala para ver si es un ajuste para usted.

Bueno, estás en el lugar correcto.

En este artículo, obtendrá una visión completa pero sucinta de LeSS para que pueda tomar una decisión informada sin perderse en todos los detalles.

Breve reseña

Large Scale Scrum, LeSS para abreviar, es un marco ágil a escala que le guía en la adopción y aplicación de ágil a escala LeSS mantiene el núcleo de Scrum intacto: exponer las debilidades del diseño organizativo a través de un marco mínimo y permitirle resolver los complejos problemas inherentes al desarrollo, a través del control empírico del proceso y la mejora continua. LeSS trata de aplicar los «principios, el propósito, los elementos y la elegancia de Scrum en un contexto a gran escala, de la forma más sencilla posible». Entre otros principios y prácticas, utiliza el Pensamiento Lean y el pensamiento sistémico para mantener el marco y su sobrecarga lo más ligero posible y aún así guiarlo en las decisiones importantes.
De hecho, Scrum a gran escala define dos marcos de trabajo:
  • LeSS le permite escalar Scrum hasta ocho equipos de hasta ocho personas cada uno.
  • LeSS Huge le ayuda a escalar Scrum hasta unos cuantos miles de personas en un solo producto.
Si escoge el que se ajusta a su tamaño, no se cargará con lastres innecesarios. Para aclarar cualquier confusión: la palabra LeSS significa tanto Large Scale Scrum en general como el marco para organizaciones más pequeñas.

Breve historia

En 2005, Craig Larman y Bas Vodde crearon Large Scale Scrum trabajando juntos en Nokia Siemens Networks aplicando Ágil y Scrum al desarrollo de productos muy grandes y en múltiples sitios.

Desde entonces, los grupos de productos que aplican LeSS tienen un tamaño muy variado, desde dos equipos hasta 2500 personas.

Principios y prácticas

LeSS, más que cualquier otro marco ágil a escala, trata de seguir a Scrum y hacer que tomes tus propias decisiones guiado por los principios y prácticas que también guiaron a Craig Larman y Bas Vodde durante su creación.

Aplicar LeSS significa:

  • Tener claras las pocas reglas que considera imprescindibles.
  • Siguiendo la orientación de sus 10 Principios al tomar tus decisiones.
  • Estructurar tu grupo de producto según su descripción de cómo organizarse.
  • Siguiendo su descripción de los Sprints de Scrum en un contexto a gran escala.
  • Aplicando las prácticas que define para la Excelencia Técnica.
  • Tomar en serio lo que tiene que decir sobre la adopción de LeSS con éxito.
  • Atención a lo que tiene que decir sobre la coordinación y la gestión en una nueva realidad.

Reglas

LeSS sólo tiene unas pocas reglas, pero son cruciales. Especifican lo que LeSS considera imprescindible para su estructura organizativa, la gestión del producto y la forma de trabajar con múltiples equipos en un único Sprint a nivel de producto.

Para todo lo demás eres libre de tomar tus propias decisiones guiadas por los mismos principios que guiaron a los autores de LeSS en su creación.

I won’t repeat the LeSS rules here, but I do advocate keeping them front and center at all times so they can be referred to often (they’re only two pages!).

Principios

LeSS puede ser magro en reglas debido a sus diez principios para guiar sus decisiones para todo lo que no considera esencial (una necesidad).

  • Scrum a gran escala es Scrum
  • Más con LeSS
  • Pensamiento sistémico
  • Pensamiento Lean
  • Control de procesos empíricos
  • Transparencia
  • Mejora continua hacia la perfección
  • Centrado en el cliente
  • Enfoque en el producto completo
  • Teoría de filas

Principio 1: Scrum a gran escala es Scrum

LeSS escala el propio Scrum sin añadir procesos, artefactos o eventos de escalado diferentes.

Principio 2: Más con LeSS

LeSS le ayuda a simplificar gradualmente su organización y a basarse en la responsabilidad, la propiedad y la orientación al cliente en lugar de en las funciones, los procesos y los artefactos.

Principio 3: Pensamiento sistémico

El pensamiento sistémico ayuda a todos los miembros de la organización (no sólo a los de desarrollo de productos) a pensar en lo que está ocurriendo y ayuda a los responsables de tomar decisiones a evitar los errores del «sentido común» y las «soluciones rápidas».

Principio 4: Pensamiento Lean

Una buena analogía del Lean Thinking es «vigilar el bastón, no los corredores» [en una carrera de relevos]. Significa que las mejoras de productividad no se buscan en la utilización de los recursos (ocupación), sino en la eliminación de los residuos (material y trabajo/tiempo muerto) del proceso de producción. En otras palabras: acelerar el relevo.

El control empírico del proceso le ayuda a «fallar hacia adelante» haciendo que produzca incrementos de trabajo de su producto en ciclos cortos, y a adaptar el producto y la forma de crearlo inspeccionándolos en cada ciclo.

Principio6: Transparencia

La transparencia le ayuda a abordar los puntos débiles de los procesos, las herramientas, las técnicas, los entornos, los sitios, las políticas, las personas, los grupos, los sistemas de recompensa, etc. en toda la organización.

Principio 7: Mejora continua hacia la perfección

La mejora continua hacia la perfección dice tres cosas:

  • «Está bien no ser perfecto ahora mismo».
  • «Está bien no ser perfecto ahora mismo».
  • «Tiene que estar bien con no llegar nunca porque siempre habrá algo más que mejorar.”

Principio 8: Centrado en el cliente

En LeSS el objetivo es escalar y mantener el enfoque en el cliente a través de la organización para que los equipos en la planta baja no terminen divorciados del valor que su trabajo ofrece a los clientes.

Principio 9: Enfoque en el producto completo

LeSS aboga por mantener a todos los equipos centrados en el producto completo, no sólo en su pequeña parte.

Principio 10: Teoría de las filas

La teoría de las colas ayuda a mejorar el flujo de trabajo a través de sus procesos de desarrollo y de cartera con orientaciones para eliminar las colas y gestionar las que no pueden eliminarse.

Las colas y el inventario no sólo existen en la fabricación física, también están presentes en el desarrollo de productos.

Por ejemplo:

  • La cartera de proyectos y productos es una cola.
  • El backlog de productos es una cola.
  • El Sprint backlog es una cola.
  • Cada estado de un flujo de trabajo es una cola en la que el trabajo espera ser recogido para el siguiente paso.
  • Un servidor de integración sobrecargado es una cola.
  • Los entornos de prueba compartidos son colas.

Y también hay mucho inventario en esas colas.

  • Documentos de diseño terminados a la espera de ser implementados.
  • Cualquier código que aún no se haya liberado, o que se haya mantenido alejado de los clientes por medio de banderas de características, en diferentes etapas de finalización.
  • Las ramas de características son tanto un inventario como una especie de fila.

Practicas

La verdadera flexibilidad (es decir, la agilidad) sólo se da cuando se pueden hacer cambios en el producto de forma rápida, fácil y flexible. Eso significa excelencia técnica, para la que LeSS nombra 10 prácticas de ingeniería y diseño:
  • Integración continua
  • Entrega continua
  • Arquitectura y diseño
  • Código limpio
  • Pruebas unitarias
  • Desarrollo dirigido por pruebas (TDD)
  • Pensar en las pruebas
  • Automatización de las pruebas
  • Pruebas de aceptación
  • Especificación por ejemplo

Todas estas prácticas están interrelacionadas, dependen y se amplían mutuamente.

Puede leer más sobre la integración, entrega y despliegue continuos y su relación con las pruebas unitarias, la automatización de pruebas y las pruebas de aceptación automatizadas en ¿Qué es CI/CD? Cómo ayuda a los equipos a entregar mejor software, más rápido. En lugar de una gran arquitectura y diseño por adelantado, Ágil y LeSS adoptan un enfoque evolutivo, lo que requiere que todas las demás prácticas mantengan el código fácil de cambiar y que los equipos confíen en cambiar la arquitectura y el diseño del código sin afectar a la función. La especificación por ejemplo, tal y como se utiliza en las historias de usuario o a través del Desarrollo Dirigido por el Comportamiento, facilita las especificaciones que un ordenador puede ejecutar y que hacen viable la automatización de las pruebas a todos los niveles, incluidas las pruebas de aceptación.

Similitudes y diferencias

LeSS frente a Scrum de un solo equipo

En lugar de utilizar Scrum a nivel de equipo y aplicar diferentes métodos para planificar, coordinar y aprender con múltiples equipos, LeSS escala el propio Scrum y mantiene su núcleo intacto.

Pero hay diferencias.

Los que informa el propio LeSS:

  • Los equipos de LeSS son lo que Scrum considera el equipo de desarrollo. El equipo de Scrum no es un concepto en LeSS.
  • LeSS habla de equipos autogestionados en lugar de autoorganizados.
  • LeSS ve el papel del Scrum Master como un trabajo dedicado a tiempo completo. Sin embargo, un Scrum Master puede guiar y entrenar hasta tres equipos para ver el producto más grande y el sistema de producción.
  • LeSS no requiere que el Product Owner participe en cada Scrum Diario o Retrospectiva del equipo.
  • LeSS divide la Planificación de Sprint en dos partes.
  • LeSS espera que el Refinamiento del Backlog sea un evento formal (es una actividad en Scrum).
  • LeSS no requiere que los Sprints tengan un Objetivo del Sprint, aunque lo considera una práctica útil.

Además:

  • El Dueño del Producto no está obligado a asistir a la Refinación del Backlog. del Producto de cada equipo. Los equipos llevan a cabo el refinamiento con los clientes y los usuarios, lo que libera al Dueño del Producto para hacer un trabajo más orientado al futuro.
  • LeSS añade una Retrospectiva global para todos los equipos juntos.
  • LeSS aborda específicamente qué papel pueden seguir desempeñando los gestores y cómo pueden seguir aportando valor incluso cuando sus responsabilidades son asumidas en gran medida por el Dueño del Producto o se delegan en los Equipos.
  • Donde Scrum dice de tres a nueve en un equipo o equipo de equipos, LeSS recomienda un máximo de ocho. Se basa en observaciones durante muchas adopciones de LeSS.

Planificación y presupuesto

LeSS se ciñe a los ciclos de planificación por sprints de Scrum. En SAFe no hay ciclos de planificación globales ni eventos como la planificación trimestral de PI.
El enfoque de LeSS en todo el producto y el énfasis en los equipos de características estables de larga duración, significa que un enfoque orientado al producto es un ajuste natural para la planificación y el presupuesto. El coste por año se desprende del número y tamaño de los equipos de características y del tamaño del equipo de propietarios de productos. La pregunta que queda es cuándo estarán disponibles las correcciones y actualizaciones de características específicas. Esto puede ser tomado, en la verdadera moda de Scrum, de la priorización del Product Backlog y su experiencia con la cantidad de equipos que pueden manejar en un Sprint.

Coordinación

Tanto LeSS como LeSS Enorme evitan ritualizar la coordinación entre equipos en eventos.

LeSS declara explícitamente: «Coordinación: Sólo hablar, comunicar en código, viajeros, espacio abierto y comunidades».

En otras palabras:

  • Colaboración entre equipos según sea necesario en arquitectura, diseño, modelado, etc.
  • Utilizar el código fuente como fuente de conocimientos sobre el producto.
  • Utilizar la tecnología» del Espacio Abierto para compartir información, conocimientos y experiencias.
  • Promover las interacciones entre equipos a través de la observación de los Scrums diarios de los demás y simplemente sentarse haciendo que uno o más miembros se sienten con otro equipo (Viajeros).
  • Formar Comunidades de Práctica (CoP) autoorganizadas de voluntarios con un interés compartido. Apoyar a los líderes informales, coordinadores de CoP, que surgen de forma natural en el grupo por su interés más que medio en el tema.
  • Utilice las CoP para difundir el conocimiento a través de sus equipos de características interfuncionales. Tienen el mismo objetivo que el antiguo sistema matricial, pero su enfoque es fundamentalmente diferente.

Teoría de las filas

LeSS es el único marco ágil a escala que acepta explícitamente todas las implicaciones de la teoría de las colas y la defiende para guiar sus decisiones de mejora. Eso significa eliminar las colas, no solo gestionarlas mediante la gestión de los niveles de trabajo en curso (WIP). LeSS valora la reducción de los niveles de WIP por muchas razones, pero califica la invocación de la Ley de Little para decir que conduce automáticamente a una reducción de los tiempos de ciclo, un mito. Esto se debe a que la prueba de la Ley de Little, como afirma LeSS LeSS «depende de condiciones y suposiciones que no están en absoluto garantizadas o incluso son comúnmente ciertas en dominios de alta variabilidad como el software». Esto es ciertamente cierto cuando se mide en periodos de tiempo relativamente cortos (o matemáticamente) finitos.

Funciones y responsabilidades clave

En una organización de LeSS no hay lugar para los gestores de proyectos ni para una oficina de gestión de programas/proyectos (PMO). No los necesita porque sus responsabilidades se transfieren a un Dueño de producto y a los equipos de características, y para evitar confusiones y potencialmente incluso guerras territoriales.

En una organización LeSS, los equipos de características hacen el trabajo de desarrollo.

Son lo que otros llamarían equipos de producto. Cada equipo crea y es responsable de las características centradas en el cliente de principio a fin, en lugar de componentes o una capa técnica. Permanecen juntos a largo plazo. Se autogestionan y son interfuncionales: si se unen, sus miembros tienen todas las habilidades que necesitan para producir un incremento que se pueda enviar.

Son guiados y entrenados por un Scrum Master. En LeSS este es un trabajo dedicado a tiempo completo, aunque un Scrum Master puede servir hasta tres equipos.

Todos los equipos de características tienen el mismo Dueño de Producto y comparten un único Backlog de Producto.

El Dueño de producto puede tener un equipo de Dueños de producto en el que otros Gestores de producto apoyan al Dueño de producto. Juntos, suelen denominarse Gestión de Producto.

El Dueño de producto (equipo) conecta a los clientes/usuarios y a los equipos para que éstos puedan realizar un refinamiento detallado del backlog con ellos directamente. Como el Dueño de producto no necesita actuar como intermediario en esto, él/ella puede centrarse en el descubrimiento del producto con los clientes.

Nótese que en LeSS el Dueño de producto y los equipos de características son pares. LeSS, como Scrum, busca explícitamente mantener un equilibrio de poder entre ellos.

LeSS Enorme

LeSS Enorme agrupa a los equipos de características en áreas de requisitos de productos, es decir, áreas principales de requisitos del cliente, en lugar de capas del sistema o subsistemas arquitectónicos.

Introduce un Dueño de producto de área (APO) en el equipo del Dueño de producto, y cada APO se centra en una única área de requisitos del producto.

Cada elemento de la lista de espera del producto se asigna a una única área de requisitos del producto. El Area Backlog es entonces simplemente un filtro en el backlog completo.

Estructura organizativa

Muchas organizaciones que han hecho la transición a LeSS siguen teniendo gerentes. LeSS es uno de los pocos marcos que aborda específicamente cómo pueden reinventarse y aportar valor a pesar de perder muchas de sus responsabilidades tradicionales.

Less Huge Organizational Structure 1

El Jefe del Grupo de Producto es el responsable jerárquico de todos los equipos que trabajan en el producto. Apoya a los equipos de características, ayudándoles a superar los obstáculos y a adquirir y mejorar sus habilidades.

El Departamento de Desactivación no es un departamento real, sino el nombre que engloba a los departamentos tradicionales de cascada como el de Análisis de Negocio, el de Control de Calidad y Pruebas y el de Arquitectura. No hay lugar para ellos en LeSS y los desmantelará a medida que avance en su adopción de LeSS. Su gente se transfiere entonces para convertirse en miembros de los equipos de características.

LeSS Enorme

En lugar de utilizar las áreas de requisitos del producto para la estructura organizativa, LeSS Enorme le propone estructurar su organización por sitio. Esto mantiene intacta la organización por línea local y ayuda a seguir siendo flexible y adaptable en cuanto a las áreas de requisitos que desea o necesita (no es necesario cambiar la organización cuando se cambian las áreas de requisitos). Aunque desmantele los departamentos que componen el Departamento de Desafíos, en las grandes organizaciones sigue siendo rentable tener un grupo de apoyo que gestione y dirija el entorno de desarrollo. Manténgalo pequeño y céntrese en cómo pueden ayudar a los equipos en lugar de prescribir lo que los equipos pueden y no pueden utilizar. LeSS considera que el coaching es fundamental para el éxito de su transición. En LeSS Enorme, tiene su propio departamento de Competencia y Coaching centrado en la mejora continua a través de la observación, la formación y el coaching

Reuniones clave, ciclos, cadencias de entrega

Un Sprint en LeSS es casi idéntico al Sprint de Scrum de un solo equipo.

Todos los equipos comienzan y terminan el Sprint al mismo tiempo.

Todos los equipos trabajan a partir de un único Product Backlog.

Todos los equipos utilizan la misma Definición de Hecho.

Todos los equipos trabajan hacia un único Incremento de Producto Potencialmente Enviable.

Planificación del Sprint

Un Sprint comienza con la Planificación del Sprint para todos los equipos al mismo tiempo.

Se divide en dos partes.

  • 1. Planificación del Sprint Uno
El Dueño de producto y los representantes de todos los equipos deciden en qué elementos trabajará cada equipo y discuten cualquier cuestión abierta que no se haya resuelto durante el refinamiento del backlog. Además, los equipos identifican qué necesidad hay de coordinación, si es que la hay. Tenga en cuenta que LeSS dice explícitamente que el Scrum Master no debe ser el representante de un equipo. Siendo un trabajo dedicado en LeSS, el Scrum Master tiene un conjunto completamente diferente de habilidades y experiencia que alguien en quien un equipo confía para hacer juicios sobre el impacto de la carga de trabajo y las dependencias de los elementos de trabajo.
  • 2. Planificación del Sprint Dos
Esto es principalmente lo mismo que en Scrum de un solo equipo. Los equipos planifican su Sprint en detalle, decidiendo cómo van a conseguir que sus elementos estén «hechos». Cuando los equipos van a trabajar en elementos similares o relacionados, pueden hacer su Sprint Planning en el mismo lugar para que puedan diseñar los elementos juntos y comunicarse fácilmente sobre el trabajo compartido y las oportunidades de colaboración, ya que de otra manera planifican su Sprint por equipo.

Scrum diario

Cada equipo realiza sus propios Scrums diarios. No tienen que ser al mismo tiempo. Eso facilita la acogida de observadores de otros equipos para compartir información y conocimientos.

Refinamiento de Backlog de productos (PBR)

Durante el Sprint, los equipos celebran sus propias reuniones con los clientes y los usuarios, pero no con el Dueño de producto, para perfeccionar los elementos del backlog del producto en los que probablemente se trabajará en el (los) siguiente(s) Sprint(s). Estas reuniones no tienen por qué celebrarse al mismo tiempo, pero los equipos pueden decidir perfeccionar juntos elementos similares y relacionados. Opcionalmente, los equipos pueden llevar a cabo un PBR general que incluya al Dueño de producto para decidir qué equipo trabajará probablemente en qué elementos.

Revisión de Sprint

La Revisión del Sprint en LeSS es una reunión de todo el equipo que incluye al Dueño de producto, a los clientes y usuarios y a otras personas con interés en el producto o en el incremento.

Retrospectiva

Al igual que la Planificación de Sprint, la Retrospectiva se divide en dos partes.

En primer lugar, cada equipo lleva a cabo su retrospectiva específica del equipo como lo harían en Scrum de un solo equipo.

A continuación, se realiza una retrospectiva general a la que asisten el Dueño de producto, los Scrum Master de los equipos y representantes rotativos de cada equipo. Esta segunda parte se centra en cómo todos los equipos están trabajando juntos en un único sistema de desarrollo.

LeSS Enorme

No hay eventos adicionales (reuniones). El Dueño de producto y los Dueños de producto de área son el pegamento entre todos los equipos.

LeSS Huge es la ejecución paralela de Sprints de LeSS por todas las áreas de requisitos.

Métodos y técnicas

Aparte de las prácticas para la excelencia técnica, , LeSS no prescribe ningún método o técnica.

Errores comunes

LeSS tiene los mismos errores que Scrum y que cualquier adopción ágil en más de un equipo.

Los mayores errores específicos de LeSS son:

  • no adoptar la colaboración entre equipos en la arquitectura, el diseño y el modelado y, por lo tanto, no hacer que las opciones y soluciones sean conocidas y estén disponibles en todos los equipos.
  • No esforzarse por desmantelar los departamentos que no se han hecho y mantener a los gestores de proyectos y a la Oficina de Gestión de Proyectos, con lo que se reduce la claridad y es probable que se produzcan guerras territoriales improductivas y que resten energía, ya que a nadie le gusta perder partes de su reino.
  • no romper la relación de subordinación de los miembros del equipo interfuncional con sus antiguos gestores y, por tanto, ponerlos en una situación de lealtades conflictivas.

Cómo empezar

LeSS es uno de los pocos enfoques para escalar ágilmente que habla explícitamente de los principios, retos y partes esenciales y prácticas para adoptar adoptar LeSS y LeSS Enorme. Así que aprovéchelo cuando comience su adopción de LeSS.

Algunos aspectos básicos que hay que poner en práctica para que la adopción sea más exitosa:

  • Poner a todos en la misma página en su conocimiento y comprensión de Scrum y LeSS. Invertir en varios días de formación para todos.
  • Conseguir que todo el mundo esté en la misma página sobre el producto completo en el que todos están trabajando.
  • Utilizar una fuerte Definición de Hecho (en lugar de una débil que refleje la realidad actual) y crear equipos interfuncionales que puedan cumplir con ellos moviendo a la gente (¡dejando que se ofrezcan como voluntarios!) de los Departamentos no hechos a ellos.
  • Deja claro que sólo el Dueño de producto puede dar trabajo a los equipos. No querrás que ningún equipo se vea interrumpido ni se sienta obligado a atender peticiones aparentemente razonables del jefe de línea, de ventas, de recursos humanos o incluso del director general.
  • Los jefes de proyecto no tienen ningún papel en el LeSS, pero pueden estar presentes mientras usted pone las cosas en orden. Durante ese tiempo, manténgalos lo más lejos posible de los equipos, porque es probable que interrumpan y causen confusión sobre si los miembros del equipo deben seguir actuando sobre lo que dicen. Véase el punto anterior.

Más información

Craig Larman y Bas Vodde – los autores de Large Scrum – escribieron tres libros sobre LeSS y su experiencia trabajando con clientes para aplicar LeSS para escalar Scrum.
  • Escalar el desarrollo Lean y Ágil (2009)
  • Prácticas para escalar el desarrollo Lean y Ágil (2010)
  • Scrum a gran escala: Más con LeSS (2015)

Los capítulos de estos libros están disponibles en línea:

  • Introducción a LeSS (Capítulo 2 del libro de LeSS) – donde puede encontrar muchos detalles sobre los temas tratados (y no tratados) en este artículo.
  • Inspeccionar y adaptar el capítulo de Prácticas para escalar
  • Contratos Ágiles
  • Diseño y Arquitectura
  • Pensamiento Lean
  • Equipos de características
La Ágil Alliance tiene un artículo muy interesante sobre LeSS sin Scrum. Habla de un enfoque que consiste en adoptar primero el diseño organizativo de LeSS y solo después introducir Scrum.

¿Está preparado para hacer más con LeSS?

Si suscribe la idea de «menos es más» y quiere mantener los gastos generales al mínimo. Si aprecia que todo el mundo se centre en el producto en todo momento. Si se siente cómodo con la ejecución de experimentos y la adaptación sobre la marcha. Si le gusta que los equipos progresen en su adopción de Scrum a su propio ritmo. Entonces usted está listo para adoptar Scrum a gran escala como su marco para escalar ágil. Su primer paso hacia eso sería aprender más sobre LeSS, especialmente sus principios básicos y sus principios para adoptarlo. Recomiendo hacerlo colectivamente utilizando las mismas fuentes o formadores. Esto asegura que todos los involucrados comiencen en el mismo nivel de conocimiento y comprensión, lo que mejorará las conversaciones en torno a su adopción. Si no está preparado para adoptar LeSS, consulte nuestra visión general de los marcos ágiles a escala.
Signup

Signup for updates!

[wpforms id=»8824″]

Less Structure Overview

Principles

¡La vida es buena cuando sus equipos ágiles están sincronizados!

Solicite una demostración personalizada de SwiftEnterprise.