Refuerza foco en producto completo El enfoque de un Product Backlog, un Product Owner, un Sprint y un incremento integrado ayuda a que todos los equipos trabajen sobre el mismo producto, con prioridades comunes y feedback real de cliente.
1
Reduce dependencias mediante feature teams La formación aborda cómo evolucionar desde component teams hacia feature teams capaces de entregar valor end-to-end. Esto reduce handoffs, colas, esperas y coordinación artificial entre departamentos.
Personaliza el temario al 100% para tu equipo
Diseñamos una formación a medida utilizando los documentos y flujos de trabajo reales de tu empresa.
Nueva Plataforma de E-learningFormación en directo con plataforma de apoyo para reforzar el aprendizaje
Acceso a las grabaciones
Los alumnos podrán revisar las sesiones grabadas para repasar conceptos clave, recuperar explicaciones concretas o reforzar aquellos contenidos que necesiten después de la clase en directo.
Recursos formativos
Materiales, sesiones grabadas y documentación de apoyo quedan centralizados en la plataforma para que el equipo pueda consultarlos durante y después de la formación.
Confirmación de asistencia
La plataforma permite registrar y confirmar la asistencia de los participantes, facilitando el seguimiento de la formación y la gestión documental necesaria para la bonificación FUNDAE.
Programa formativo
Temario del curso
Encuentra todo el temario del curso aquí.
Temario
Situar LeSS como Large Scale Scrum, un marco para escalar Scrum manteniendo su simplicidad, empirismo y foco en producto.
Diferenciar LeSS de Scrum de un solo equipo, SAFe, Nexus, Scrum@Scale, modelos híbridos, PMO Agile y escalado por proyectos.
Comprender que LeSS no intenta “coordinar equipos Scrum separados”, sino crear una organización de producto con varios equipos trabajando juntos.
Analizar por qué LeSS insiste en un solo producto, un solo Product Owner, un solo Product Backlog y un incremento integrado.
Identificar cuándo LeSS encaja: varios equipos sobre un mismo producto, dependencias frecuentes, silos técnicos y necesidad de aprendizaje rápido.
Reconocer cuándo LeSS no es recomendable: productos realmente separados, equipos sin base Scrum, baja calidad técnica o ausencia de sponsorship.
Comprender la diferencia entre adoptar LeSS y añadir ceremonias multi-equipo a una organización funcional tradicional.
Revisar los problemas que LeSS intenta eliminar: coordinación centralizada, handoffs, backlogs por equipo, component teams y managers de asignación.
Preparar una conversación inicial con dirección sobre estructura, producto, equipos, calidad, liderazgo y cambio organizativo.
Establecer el recorrido del curso desde fundamentos hasta LeSS Huge, adopción, excelencia técnica y Proyecto Final.
Situar LeSS como Large Scale Scrum, un marco para escalar Scrum manteniendo su simplicidad, empirismo y foco en producto.
Diferenciar LeSS de Scrum de un solo equipo, SAFe, Nexus, Scrum@Scale, modelos híbridos, PMO Agile y escalado por proyectos.
Comprender que LeSS no intenta “coordinar equipos Scrum separados”, sino crear una organización de producto con varios equipos trabajando juntos.
Analizar por qué LeSS insiste en un solo producto, un solo Product Owner, un solo Product Backlog y un incremento integrado.
Identificar cuándo LeSS encaja: varios equipos sobre un mismo producto, dependencias frecuentes, silos técnicos y necesidad de aprendizaje rápido.
Reconocer cuándo LeSS no es recomendable: productos realmente separados, equipos sin base Scrum, baja calidad técnica o ausencia de sponsorship.
Comprender la diferencia entre adoptar LeSS y añadir ceremonias multi-equipo a una organización funcional tradicional.
Revisar los problemas que LeSS intenta eliminar: coordinación centralizada, handoffs, backlogs por equipo, component teams y managers de asignación.
Preparar una conversación inicial con dirección sobre estructura, producto, equipos, calidad, liderazgo y cambio organizativo.
Establecer el recorrido del curso desde fundamentos hasta LeSS Huge, adopción, excelencia técnica y Proyecto Final.
Tema 1: LeSS como Scrum a escala: qué es, para qué sirve y cuándo aplicarlo
Situar LeSS como Large Scale Scrum, un marco para escalar Scrum manteniendo su simplicidad, empirismo y foco en producto.
Diferenciar LeSS de Scrum de un solo equipo, SAFe, Nexus, Scrum@Scale, modelos híbridos, PMO Agile y escalado por proyectos.
Comprender que LeSS no intenta “coordinar equipos Scrum separados”, sino crear una organización de producto con varios equipos trabajando juntos.
Analizar por qué LeSS insiste en un solo producto, un solo Product Owner, un solo Product Backlog y un incremento integrado.
Identificar cuándo LeSS encaja: varios equipos sobre un mismo producto, dependencias frecuentes, silos técnicos y necesidad de aprendizaje rápido.
Reconocer cuándo LeSS no es recomendable: productos realmente separados, equipos sin base Scrum, baja calidad técnica o ausencia de sponsorship.
Comprender la diferencia entre adoptar LeSS y añadir ceremonias multi-equipo a una organización funcional tradicional.
Revisar los problemas que LeSS intenta eliminar: coordinación centralizada, handoffs, backlogs por equipo, component teams y managers de asignación.
Preparar una conversación inicial con dirección sobre estructura, producto, equipos, calidad, liderazgo y cambio organizativo.
Establecer el recorrido del curso desde fundamentos hasta LeSS Huge, adopción, excelencia técnica y Proyecto Final.
Tema 2: Principios de LeSS: decisiones guiadas por pensamiento sistémico
Trabajar el principio “Large-Scale Scrum is Scrum” para evitar modelos de escalado que conservan Scrum solo en los equipos.
Aplicar empirismo como base para inspeccionar producto, proceso, estructura, roles, métricas y resultados reales.
Reforzar transparencia sobre trabajo, dependencias, retrasos, defectos, decisiones de producto, impedimentos y aprendizaje.
Entender “More with LeSS” como reducción de roles, artefactos, procesos, handoffs y capas que no añaden valor.
Aplicar pensamiento sistémico para evitar mejorar un equipo a costa del flujo completo de producto.
Utilizar Lean Thinking para reducir desperdicio, colas, multitarea, traspasos, trabajo parcialmente hecho y burocracia.
Mantener foco en cliente y producto completo, evitando que cada equipo optimice “su componente” o “su parte”.
Trabajar mejora continua hacia la perfección mediante experimentos pequeños, aprendizaje y revisión estructural.
Aplicar teoría de colas para entender por qué demasiada demanda, WIP y dependencias destruyen predictibilidad.
Convertir los principios en criterios concretos para tomar decisiones difíciles durante una adopción LeSS.
Tema 3: Basic LeSS: estructura, reglas y funcionamiento de 2 a 8 equipos
Comprender Basic LeSS como aplicación de Scrum a un producto con entre dos y ocho equipos.
Diseñar una estructura con equipos reales, estables, cross-functional, self-managing y orientados a cliente.
Crear un único Product Backlog para el producto completo, evitando backlogs por equipo, área, componente o departamento.
Definir un único Product Owner responsable de priorización global del producto, apoyado por equipos que refinan con clientes y stakeholders.
Establecer una Definition of Done común para todos los equipos, con posibilidad de que algún equipo añada criterios más exigentes.
Trabajar un único Sprint común donde todos los equipos comienzan y terminan a la vez.
Entregar un único incremento potencialmente entregable e integrado al final de cada Sprint.
Entender por qué los Scrum Masters no deben centrarse solo en “su equipo”, sino en el sistema organizativo completo.
Revisar el papel opcional y cambiante de managers dentro de una adopción LeSS.
Preparar un mapa visual de Basic LeSS para explicar estructura, eventos, backlogs, roles y flujo de valor.
Tema 4: Definición amplia de producto y foco en el whole product
Analizar qué significa producto en LeSS y por qué debe definirse de forma amplia y centrada en cliente.
Evitar definiciones estrechas de producto basadas en aplicaciones internas, componentes técnicos, canales o departamentos.
Identificar usuarios, clientes, journeys, outcomes, capacidades y problemas reales que justifican la definición de producto.
Revisar consecuencias de tener productos artificialmente pequeños: múltiples Product Owners, dependencias, prioridades fragmentadas y baja adaptabilidad.
Diseñar una conversación con stakeholders para ampliar progresivamente la definición de producto.
Relacionar whole product focus con un Product Backlog único, equipos feature team y Sprint Review común.
Detectar señales de producto mal definido: backlogs duplicados, integraciones tardías, responsables por componente y roadmap inconexo.
Crear criterios para separar productos de verdad frente a áreas funcionales que solo parecen productos.
Trabajar ejemplos en banca, ecommerce, SaaS, administración pública, industria, telco y plataformas internas.
Documentar una definición de producto que sirva para reorganizar equipos, backlog, métricas y ownership.
Tema 5: Product Owner único y Product Backlog común
Comprender por qué LeSS mantiene un único Product Owner para el producto completo.
Analizar riesgos de múltiples Product Owners con prioridades locales, roadmaps inconsistentes y conflictos de backlog.
Definir responsabilidades del Product Owner en priorización, visión, maximización de valor y toma de decisiones económicas.
Diseñar mecanismos para que los equipos trabajen directamente con clientes, usuarios y stakeholders durante el refinamiento.
Evitar que el Product Owner se convierta en cuello de botella de aclaraciones, análisis funcional o microgestión.
Crear un Product Backlog común con items orientados a valor, aprendizaje, riesgo, cliente y producto completo.
Gestionar dependencias desde el backlog reduciéndolas mediante feature teams, slicing y colaboración multi-equipo.
Priorizar con criterios de valor, coste de retraso, riesgo, aprendizaje, urgencia y capacidad real.
Refinar items de forma colaborativa para que varios equipos puedan entender opciones de implementación.
Documentar políticas de backlog para evitar que vuelva a fragmentarse por equipos o componentes.
Tema 6: Feature teams y rediseño organizativo
Diferenciar feature teams de component teams, function teams, project teams y grupos especializados.
Diseñar equipos capaces de entregar funcionalidades end-to-end con impacto visible en cliente o usuario.
Identificar skills necesarios para que un equipo pueda trabajar sobre distintas partes del producto.
Reducir dependencias mediante aprendizaje cruzado, pair/mob programming, comunidades técnicas y mentoring.
Gestionar la transición desde component teams hacia feature teams sin romper producción ni conocimiento crítico.
Detectar falsas feature teams que dependen de equipos externos para testing, UX, arquitectura, datos, despliegue o seguridad.
Rediseñar la estructura para que el equipo no sea una “bolsa de recursos”, sino una unidad estable con propósito.
Trabajar especialización flexible: personas con fortalezas concretas, pero equipos responsables del resultado completo.
Ajustar métricas e incentivos para evitar que cada equipo optimice velocidad local sin entregar producto integrado.
Crear un mapa de adopción de feature teams con pasos, riesgos, resistencias, experimentos y criterios de progreso.
Tema 7: Coordinación descentralizada entre equipos
Sustituir coordinación centralizada por mecanismos ligeros basados en conversación directa y ownership compartido.
Aplicar “Just Talk” como primera herramienta de coordinación antes de crear comités, managers de dependencias o reuniones recurrentes.
Utilizar comunicación en código para que integración, tests, interfaces y diseño comuniquen decisiones reales entre equipos.
Crear travelers, scouts, component mentors, open spaces y comunidades cuando ayudan a resolver dependencias concretas.
Diseñar cross-team meetings solo cuando existe una necesidad real, con objetivo, duración, participantes y resultado claros.
Evitar Scrum of Scrums mecánico si se convierte en reporte de estado y no en coordinación útil.
Preparar visualizaciones de dependencias que ayuden a los equipos a hablar, no a delegar responsabilidad en un coordinador.
Fomentar que los equipos se autoorganicen para dividir trabajo durante Sprint Planning One.
Revisar dependencias recurrentes como síntoma de mala estructura, no como un problema normal que gestionar eternamente.
Crear acuerdos de coordinación para decisiones de arquitectura, integración, testing, UX, datos y releases.
Tema 8: Sprint común, Sprint Planning One y Sprint Planning Two
Comprender el Sprint común como unidad de aprendizaje y entrega para todos los equipos del producto.
Facilitar Sprint Planning One con Product Owner y representantes o miembros de todos los equipos.
Seleccionar items de Product Backlog de forma colaborativa, identificando qué equipos podrían trabajar cada item.
Explorar oportunidades de cooperación entre equipos cuando los items están relacionados.
Aclarar preguntas finales con Product Owner, usuarios, stakeholders o equipos antes de comprometer el trabajo.
Ejecutar Sprint Planning Two en cada equipo para decidir cómo abordar los items seleccionados.
Realizar Sprint Planning Two multi-equipo cuando el trabajo está muy relacionado y conviene diseñar en una misma sala.
Evitar que Sprint Planning One sea una asignación top-down de trabajo por parte de managers o Product Owner.
Crear Sprint Backlogs por equipo manteniendo un objetivo común de producto e incremento integrado.
Revisar calidad de la planificación mediante claridad, dependencias reducidas, riesgos visibles y capacidad real.
Tema 9: Product Backlog Refinement en contextos multi-equipo
Diseñar refinamiento continuo para que items futuros estén suficientemente entendidos antes del Sprint.
Aplicar multi-team Product Backlog Refinement cuando varios equipos necesitan aprender juntos o coordinar implementación.
Mantener single-team refinement cuando el item será trabajado por un equipo y no requiere colaboración amplia.
Usar Overall PBR corto para seleccionar qué items conviene refinar y qué equipos podrían participar.
Involucrar directamente a clientes, usuarios, soporte, operaciones y stakeholders cuando aportan información relevante.
Dividir items en vertical slices que generen aprendizaje y reduzcan dependencias técnicas.
Evitar refinamiento como fase de análisis funcional centralizada antes de que los equipos “reciban requisitos”.
Revisar Definition of Ready con cuidado para no crear un gate burocrático que contradice empirismo.
Mejorar backlog mediante ejemplos, criterios de aceptación, hipótesis, riesgos, datos, UX, arquitectura y NFRs.
Medir calidad de refinamiento por aprendizaje, reducción de dependencia y capacidad de entregar incremento integrado.
Tema 10: Sprint Review común y aprendizaje con clientes
Preparar una Sprint Review de producto común para todos los equipos y stakeholders relevantes.
Mostrar el incremento integrado, no demos aisladas de trabajo parcial por equipo o componente.
Utilizar formato bazaar o science fair cuando hay muchos items y conviene facilitar conversación distribuida.
Invitar a clientes, usuarios, soporte, negocio, operaciones y áreas que puedan aportar feedback real.
Revisar el Product Backlog durante la Sprint Review a partir de lo aprendido sobre el incremento.
Evitar que la Sprint Review sea una presentación ceremonial de estado para managers.
Capturar feedback accionable sobre valor, usabilidad, calidad, riesgo, mercado y prioridades futuras.
Relacionar la Review con decisiones de producto y no solo con aceptación de funcionalidades terminadas.
Crear métricas de aprendizaje: hipótesis validadas, cambios de prioridad, feedback útil y decisiones tomadas.
Diseñar una Sprint Review que refuerce whole product focus y responsabilidad compartida de todos los equipos.
Tema 11: Retrospectivas de equipo y Overall Retrospective
Mantener retrospectivas por equipo para mejorar colaboración local, técnica, dinámica y flujo interno.
Facilitar Overall Retrospective después de las retrospectivas de equipo para abordar problemas sistémicos.
Incluir Product Owner, Scrum Masters, representantes rotativos de equipos y managers cuando existan.
Trabajar problemas cross-team: estructura, dependencias, Definition of Done, integración, herramientas, liderazgo y políticas.
Formular experimentos de mejora con hipótesis, acción, owner, duración y criterio de evaluación.
Evitar que la Overall Retrospective se convierta en una reunión de quejas sin capacidad de cambio.
Diferenciar problemas que un equipo puede resolver de problemas que requieren rediseño organizativo.
Revisar impedimentos recurrentes que aparecen Sprint tras Sprint y siguen sin atacarse en el sistema.
Medir progreso de experimentos y eliminar prácticas que no generan mejora real.
Crear una cultura de mejora continua donde el cambio estructural es normal, no un proyecto extraordinario.
Tema 12: Scrum Masters en LeSS y coaching del sistema completo
Comprender que el Scrum Master en LeSS trabaja con equipos, Product Owner, organización y prácticas de desarrollo.
Evitar que el Scrum Master sea secretario de ceremonias, administrador de Jira o gestor de impedimentos locales.
Diseñar un foco sistémico: estructura, dependencias, calidad, coordinación, liderazgo, métricas e impedimentos organizativos.
Acompañar a varios equipos sin perder profundidad de coaching ni convertirse en coordinador central.
Facilitar aprendizaje entre equipos mediante comunidades, open spaces, mentoring y conversaciones directas.
Ayudar al Product Owner a trabajar con equipos y stakeholders sin crear una capa de analistas intermedios.
Retar a managers cuando políticas, incentivos o estructura bloquean adaptabilidad.
Usar coaching, mentoring, teaching y facilitation según necesidad real del sistema.
Crear una agenda de mejora basada en observación, Go See, datos, experimentos y feedback.
Medir impacto del Scrum Master por mejora del sistema, no por cumplimiento de ceremonias.
Tema 13: Managers y liderazgo en una adopción LeSS
Redefinir el papel del manager desde asignar trabajo hacia mejorar la capacidad del sistema de desarrollo.
Practicar Go See para entender problemas reales en el lugar donde ocurren, no desde reportes filtrados.
Eliminar políticas, estructuras, approvals, métricas e incentivos que generan silos y optimización local.
Fomentar Stop & Fix cuando la calidad, integración o flujo se deterioran.
Apoyar experimentos sobre estructura, equipos, ownership, herramientas y prácticas técnicas.
Evitar que managers mantengan control diario mientras el lenguaje oficial habla de self-management.
Trabajar pérdida de poder percibido, identidad profesional y resistencia de mandos intermedios.
Diseñar nuevas responsabilidades para managers que siguen aportando valor: desarrollo de personas, sistema y capacidad.
Crear conversaciones difíciles sobre proyectos, departamentos, especialización, reporting y presupuestos.
Medir liderazgo LeSS por reducción de obstáculos y crecimiento de autonomía real de equipos.
Tema 14: Technical Excellence en LeSS
Comprender que escalar Scrum sin excelencia técnica amplifica deuda, defectos, integración tardía y lentitud.
Elevar la Definition of Done hacia un incremento potencialmente entregable cada Sprint.
Implantar integración continua real con commits frecuentes, tests automatizados y feedback rápido.
Aplicar prácticas de clean code, refactoring, TDD, pair programming, mob programming y revisión de código según contexto.
Diseñar test automation en múltiples niveles: unit, integration, acceptance, contract, end-to-end y exploratorio.
Incorporar Specification by Example y aceptación temprana para reducir ambigüedad y retrabajo.
Gestionar arquitectura evolutiva sin crear un equipo de arquitectura que bloquea el flujo.
Hacer visible deuda técnica, defectos, fragilidad, entornos lentos, pipelines rotos y problemas de calidad.
Evitar que equipos feature team dependan de grupos externos para testing, integración, release o validación.
Crear una estrategia técnica de mejora incremental alineada con Whole Product Focus.
Tema 15: Arquitectura, comunidades y aprendizaje técnico transversal
Diseñar arquitectura como responsabilidad compartida de equipos, con liderazgo técnico distribuido y comunidades activas.
Crear comunidades de práctica para arquitectura, testing, UX, DevOps, seguridad, datos, observabilidad y performance.
Usar component mentors para ayudar a equipos a trabajar en zonas del producto donde aún no tienen experiencia.
Evitar component owners que se convierten en gatekeepers y bloquean cambios de otros equipos.
Documentar decisiones relevantes con ADRs ligeros, ejemplos, pruebas y documentación viva.
Promover aprendizaje cruzado mediante pairing, mobbing, dojos, code reading y trabajo conjunto entre equipos.
Gestionar estándares técnicos como acuerdos evolutivos, no como normas impuestas por un comité externo.
Revisar dependencias técnicas recurrentes como señal de arquitectura o estructura organizativa problemática.
Conectar arquitectura con Product Backlog mediante enablers, deuda técnica visible y criterios de Done.
Crear mecanismos para mantener coherencia técnica sin perder autonomía de equipos.
Tema 16: LeSS Huge: Requirement Areas, Area Product Owners y escalado superior
Comprender LeSS Huge como ampliación de LeSS para productos con más de ocho equipos.
Mantener los elementos comunes: un Product Backlog, un Product Owner global, un Sprint común y un incremento integrado.
Diseñar Requirement Areas agrupando requisitos relacionados desde la perspectiva del cliente.
Crear Area Product Backlogs como vistas más granulares del Product Backlog único.
Definir Area Product Owners que actúan como Product Owners hacia equipos de su Requirement Area.
Mantener un Product Owner global responsable de priorización del producto completo y asignación de equipos a áreas.
Evitar aplicar LeSS Huge antes de tiempo, ya que añade overhead y riesgo de optimización local.
Diseñar Requirement Areas de 4 a 8 equipos, evitando áreas demasiado pequeñas o demasiado grandes.
Gestionar sincronización frecuente entre Product Owner y Area Product Owners.
Planificar adopciones LeSS Huge de forma incremental, con paciencia, aprendizaje y revisión estructural.
Tema 17: Adopción de LeSS: empezar, cambiar estructura y sostener mejora
Preparar una adopción LeSS entendiendo que implica cambio estructural, político y cultural, no solo formación.
Identificar producto, equipos, managers, dependencias, stakeholders, calidad técnica y readiness antes de empezar.
Aplicar el principio de cambiar estructura al inicio dentro del product group cuando se adopta Basic LeSS.
Adoptar de forma evolutiva en la organización más amplia, usando experimentos y mejora continua.
Evitar crear un “equipo de transformación” que sustituye responsabilidad real de managers y equipos.
Diseñar una visión de cambio basada en problemas visibles: lentitud, dependencias, handoffs, baja calidad o poca orientación a cliente.
Preparar formación por rol: equipos, Product Owner, Scrum Masters, managers, stakeholders y soporte técnico.
Gestionar resistencia ligada a pérdida de control, roles existentes, estructura funcional y financiación por proyectos.
Crear un backlog de experimentos de adopción con hipótesis, responsables, indicadores y revisión.
Medir progreso por cambios en estructura, flow, calidad, aprendizaje y resultados de producto, no por número de ceremonias.
Tema 18: LeSS frente a SAFe, Nexus, Scrum@Scale y modelos híbridos
Comparar LeSS con SAFe desde la perspectiva de complejidad organizativa, roles, eventos, portfolio y gobernanza.
Diferenciar LeSS de Nexus, que mantiene una aproximación más centrada en integración de varios Scrum Teams.
Comparar LeSS con Scrum@Scale en términos de estructura, Product Owner Cycle, Scrum Master Cycle y escalado modular.
Analizar por qué LeSS reduce roles y capas en lugar de añadir coordinación formal.
Revisar contextos donde una empresa elige LeSS por preferir simplicidad, producto único, feature teams y rediseño organizativo.
Reconocer contextos donde un modelo más prescriptivo puede resultar más fácil de vender internamente, aunque no siempre más ágil.
Evitar mezclas incoherentes como “LeSS con project managers asignando trabajo” o “LeSS con backlogs por componente”.
Crear criterios de decisión entre marcos: complejidad, cultura, liderazgo, producto, regulación, madurez técnica y tolerancia al cambio.
Analizar qué prácticas de otros modelos pueden convivir sin destruir principios LeSS.
Preparar una recomendación ejecutiva honesta sobre si LeSS es adecuado para una organización concreta.
Tema 19: Métricas en LeSS: flow, aprendizaje, valor y sistema completo
Definir métricas que ayuden a mejorar el sistema completo, no a controlar personas o comparar equipos.
Medir lead time, cycle time, throughput, WIP, defectos, retrabajo, integración, frecuencia de entrega y feedback de cliente.
Revisar métricas de producto: outcomes, adopción, satisfacción, retención, conversión, ingresos, uso y aprendizaje validado.
Detectar métricas dañinas como velocidad comparada entre equipos, porcentaje de ocupación o cumplimiento local de tareas.
Visualizar dependencias, colas, handoffs y trabajo parcialmente hecho.
Medir calidad de la Definition of Done y progreso hacia un incremento realmente entregable cada Sprint.
Usar datos en Overall Retrospective para elegir experimentos de mejora sistémica.
Crear dashboards ligeros que muestren flow y aprendizaje sin alimentar burocracia.
Revisar métricas con equipos y managers para entender causas, no para buscar culpables.
Diseñar un sistema de métricas alineado con transparencia, empirismo y whole product focus.
Tema 20: Herramientas para LeSS: Jira, Azure DevOps, Confluence y tableros físicos
Configurar herramientas de backlog para soportar un único Product Backlog y evitar backlogs separados por equipo.
Diseñar vistas por equipo, producto, Sprint, dependencias y refinamiento sin romper el backlog común.
Representar un único Sprint común con múltiples equipos trabajando sobre items del Product Backlog.
Evitar herramientas configuradas como departamentos, proyectos o componentes que refuerzan silos existentes.
Crear tableros de coordinación ligeros para dependencias, integración, risks, objetivos y mejoras sistémicas.
Utilizar Confluence, Miro, Mural o FigJam para mapas de producto, Definition of Done, experimentos y workshops.
Diseñar workflows simples que no sustituyen conversación directa por estados burocráticos.
Configurar métricas de flow sin convertir la herramienta en un sistema de reporte para managers.
Documentar convenciones de uso para que todos los equipos trabajen con lenguaje común.
Revisar periódicamente si la herramienta ayuda al empirismo o está recreando una PMO disfrazada de Agile.
Tema 21: LeSS en entornos regulados, hardware, datos y productos complejos
Adaptar LeSS a banca, seguros, salud, sector público, defensa, telecomunicaciones, automoción, industria o plataformas de datos.
Integrar compliance, seguridad, auditoría y validación como parte del incremento, no como fase posterior.
Trabajar Definition of Done con evidencias, pruebas, documentación regulatoria, trazabilidad y controles obligatorios.
Coordinar hardware, firmware, software, datos y servicios cuando el producto completo exige múltiples disciplinas.
Gestionar suppliers y equipos externos sin convertirlos en handoffs que bloquean al product group.
Aplicar feature teams cuando existen especializaciones fuertes mediante aprendizaje progresivo y comunidades.
Diseñar refinamiento temprano para riesgos regulatorios, técnicos, UX, datos, seguridad y operaciones.
Mantener Sprint Review común con stakeholders regulados o técnicos que aportan feedback relevante.
Evitar justificar waterfall completo por regulación si existen oportunidades de entrega incremental y aprendizaje.
Crear ejemplos de adopción LeSS en productos con alta criticidad, dependencias y restricciones reales.
Tema 22: Antipatrones de LeSS y señales de adopción superficial
Detectar LeSS nominal cuando existen múltiples Product Owners, múltiples backlogs y prioridades por equipo.
Identificar component teams disfrazados de feature teams que siguen dependiendo unos de otros para entregar valor.
Detectar Sprint Review fragmentada donde cada equipo enseña su parte y nadie revisa el producto integrado.
Corregir Overall Retrospective que solo lista problemas sin experimentos ni cambios estructurales.
Evitar Scrum Masters asignados solo a equipos locales sin foco en sistema organizativo.
Detectar managers que siguen asignando trabajo mientras se habla de self-management.
Revisar métricas que premian ocupación, velocidad local y cumplimiento de plan por encima de valor y aprendizaje.
Evitar que LeSS Huge se adopte prematuramente para conservar jerarquías y áreas funcionales.
Identificar herramientas configuradas de forma que refuerzan silos, componentes y proyectos.
Crear un plan de corrección de antipatrones con experimentos, conversaciones difíciles y cambios estructurales.
Tema 23: Proyecto Final
Analizar una organización simulada con varios equipos, dependencias, componentes, backlog fragmentado y baja entrega integrada.
Definir el producto de forma amplia, centrada en cliente y suficientemente útil para reorganizar equipos y backlog.
Diseñar una estructura Basic LeSS o LeSS Huge justificando número de equipos, Requirement Areas y roles necesarios.
Rediseñar equipos hacia feature teams, identificando skills faltantes, dependencias actuales y plan de aprendizaje cruzado.
Crear un Product Backlog único con items orientados a valor, enablers visibles, riesgos y criterios de refinamiento.
Definir Product Owner, Area Product Owners si aplica, Scrum Masters, managers y comunidades técnicas.
Diseñar Sprint Planning One, Sprint Planning Two, refinamiento multi-equipo, Sprint Review común y Overall Retrospective.
Crear una Definition of Done común con pasos de mejora hacia incremento integrado y potencialmente entregable.
Preparar mecanismos de coordinación descentralizada: Just Talk, communities, travelers, component mentors, open spaces y comunicación en código.
Diseñar estrategia de technical excellence con integración continua, testing, clean code, arquitectura evolutiva y reducción de deuda.
Crear un mapa de adopción con cambios estructurales iniciales, experimentos evolutivos, resistencias, riesgos y comunicación.
Definir métricas de flow, calidad, aprendizaje, dependencia, producto, satisfacción y mejora sistémica.
Identificar antipatrones probables y diseñar acciones preventivas para evitar LeSS superficial o burocrático.
Preparar una presentación ejecutiva defendiendo diseño organizativo, beneficios, riesgos, trade-offs y próximos pasos.
Perfiles profesionales
Pensado para quienes deben dominar LeSS (Large Scale Scrum) en su día a día
Scrum Masters, Agile Coaches y facilitadores de cambio
Este curso encaja con perfiles que acompañan equipos y organizaciones en procesos de escalado Agile. La formación les permite entender LeSS como cambio organizativo profundo, no como un conjunto de eventos añadidos. Trabajarán coaching, sistema completo, coordinación entre equipos, Overall Retrospective, mejora continua, experimentos y eliminación de impedimentos estructurales.
Product Owners y Product Managers
Los perfiles de producto aprenderán a trabajar con un único Product Backlog, una visión amplia de producto, priorización global, refinamiento colaborativo y contacto directo entre equipos y clientes. El curso les ayuda a evitar la fragmentación habitual de múltiples backlogs, múltiples owners y prioridades contradictorias.
Preguntas frecuentes
Resolvemos todas tus dudas sobre nuestra formación en LeSS (Large Scale Scrum)
Explora las respuestas a las preguntas que guian a nuestra comunidad. Aqui encontraras claridad sobre como funciona todo, desde el acceso hasta los detalles de los cursos. Si buscas respuestas, este es el lugar para comenzar.
LeSS, Large Scale Scrum, es un marco para aplicar Scrum a varios equipos que trabajan sobre un mismo producto. Mantiene un Product Backlog, un Product Owner, una Definition of Done común, un Sprint y un incremento integrado.
LeSS busca escalar Scrum reduciendo roles, capas y artefactos. SAFe es más prescriptivo y añade más estructura de portfolio, programas y roles. LeSS exige más rediseño organizativo y menos coordinación centralizada.
Basic LeSS se usa para productos con entre dos y ocho equipos trabajando sobre un mismo producto. Es el punto de partida habitual antes de considerar LeSS Huge.
LeSS Huge se aplica cuando hay más de ocho equipos sobre un mismo producto. Introduce Requirement Areas, Area Product Owners y Area Product Backlogs, manteniendo un Product Owner global y un Product Backlog único.
Sí. En Basic LeSS hay un único Product Owner para el producto completo. En LeSS Huge existe un Product Owner global y Area Product Owners, pero sigue existiendo un único Product Backlog global.
No necesariamente. Los managers son opcionales, pero si existen su papel cambia. Dejan de gestionar el trabajo diario y se centran en mejorar el sistema, desarrollar capacidad organizativa y eliminar impedimentos estructurales.
Sí, pero exige voluntad real de rediseñar estructura, producto, equipos y responsabilidades. No funciona bien si la empresa solo quiere añadir ceremonias sin cambiar silos, dependencias y modelos de decisión.
Sí. LeSS es Scrum a escala, por lo que conviene entender bien Scrum de un equipo antes de escalarlo. El curso repasa lo esencial, pero está orientado a personas con base Agile previa.
El curso puede alinearse con conceptos de LeSS Practitioner o LeSS Basics, pero no sustituye una formación oficial certificada por LeSS.works si la empresa necesita certificación reconocida.
Se trabaja adopción real: estructura, managers, equipos, resistencia, experimentos, feature teams, producto, métricas, technical excellence, herramientas, antipatrones y roadmap de cambio.
Sí. El Proyecto Final puede trabajar con un caso real o anonimizado de la empresa: equipos, producto, estructura, backlogs, dependencias, roles, herramientas, métricas y roadmap de adopción.
Sí, esta formación puede ser bonificable hasta el 100% a través de FUNDAE, siempre que la empresa disponga de crédito formativo suficiente y se cumplan los requisitos de comunicación, asistencia y documentación exigidos.
LeSS, Large Scale Scrum, es un marco para aplicar Scrum a varios equipos que trabajan sobre un mismo producto. Mantiene un Product Backlog, un Product Owner, una Definition of Done común, un Sprint y un incremento integrado.
LeSS busca escalar Scrum reduciendo roles, capas y artefactos. SAFe es más prescriptivo y añade más estructura de portfolio, programas y roles. LeSS exige más rediseño organizativo y menos coordinación centralizada.
Basic LeSS se usa para productos con entre dos y ocho equipos trabajando sobre un mismo producto. Es el punto de partida habitual antes de considerar LeSS Huge.
LeSS Huge se aplica cuando hay más de ocho equipos sobre un mismo producto. Introduce Requirement Areas, Area Product Owners y Area Product Backlogs, manteniendo un Product Owner global y un Product Backlog único.
Sí. En Basic LeSS hay un único Product Owner para el producto completo. En LeSS Huge existe un Product Owner global y Area Product Owners, pero sigue existiendo un único Product Backlog global.
No necesariamente. Los managers son opcionales, pero si existen su papel cambia. Dejan de gestionar el trabajo diario y se centran en mejorar el sistema, desarrollar capacidad organizativa y eliminar impedimentos estructurales.
Sí, pero exige voluntad real de rediseñar estructura, producto, equipos y responsabilidades. No funciona bien si la empresa solo quiere añadir ceremonias sin cambiar silos, dependencias y modelos de decisión.
Sí. LeSS es Scrum a escala, por lo que conviene entender bien Scrum de un equipo antes de escalarlo. El curso repasa lo esencial, pero está orientado a personas con base Agile previa.
El curso puede alinearse con conceptos de LeSS Practitioner o LeSS Basics, pero no sustituye una formación oficial certificada por LeSS.works si la empresa necesita certificación reconocida.
Se trabaja adopción real: estructura, managers, equipos, resistencia, experimentos, feature teams, producto, métricas, technical excellence, herramientas, antipatrones y roadmap de cambio.
Sí. El Proyecto Final puede trabajar con un caso real o anonimizado de la empresa: equipos, producto, estructura, backlogs, dependencias, roles, herramientas, métricas y roadmap de adopción.
Sí, esta formación puede ser bonificable hasta el 100% a través de FUNDAE, siempre que la empresa disponga de crédito formativo suficiente y se cumplan los requisitos de comunicación, asistencia y documentación exigidos.
Diseñemos hoy el curso que tu empresa necesita
Cuéntanos tus objetivos de negocio y prepararemos una propuesta formativa bonificable totalmente ad hoc
Mejora la transparencia del sistema LeSS hace visibles problemas estructurales que otras organizaciones esconden detrás de roles de coordinación. El curso enseña a usar empirismo, Overall Retrospective y métricas para mejorar el sistema completo.
3
Conecta Agile con excelencia técnica El programa incluye integración continua, test automation, clean code, arquitectura evolutiva, Specification by Example y Definition of Done común. Sin estas prácticas, escalar Scrum suele aumentar defectos y retrasos.
4
Cambia el papel de managers y liderazgo El curso ayuda a managers a pasar de asignar tareas a mejorar el sistema de desarrollo de producto. Esto permite crear autonomía real, reducir controles innecesarios y apoyar experimentos de mejora.
5
Prepara adopciones LeSS y LeSS Huge La formación cubre Basic LeSS y LeSS Huge, incluyendo Requirement Areas, Area Product Owners, adopción incremental, riesgos, antipatrones y criterios para no escalar más de lo necesario.
Después de la formación en directo, los alumnos podrán acceder a ejercicios prácticos para aplicar lo trabajado en clase y consolidar el aprendizaje con actividades guiadas.
Acceso a las grabaciones
Los alumnos podrán revisar las sesiones grabadas para repasar conceptos clave, recuperar explicaciones concretas o reforzar aquellos contenidos que necesiten después de la clase en directo.
Recursos formativos
Materiales, sesiones grabadas y documentación de apoyo quedan centralizados en la plataforma para que el equipo pueda consultarlos durante y después de la formación.
Confirmación de asistencia
La plataforma permite registrar y confirmar la asistencia de los participantes, facilitando el seguimiento de la formación y la gestión documental necesaria para la bonificación FUNDAE.
Ejercicios prácticos
Después de la formación en directo, los alumnos podrán acceder a ejercicios prácticos para aplicar lo trabajado en clase y consolidar el aprendizaje con actividades guiadas.
Practica y mejora con nuestra plataforma
Una plataforma practica, con IA integrada y pensada para que mejores desarrollando. Se adapta a tu ritmo, te corrige al instante y te muestra tu progreso real.
Correccion magica
Feedback inteligente
Aprende de cada acierto y fallo con explicaciones claras
Los managers podrán comprender cómo cambia su papel en LeSS: menos asignación diaria de trabajo y más mejora del sistema de desarrollo de producto. La formación aborda estructura organizativa, sistemas de incentivos, eliminación de silos, toma de decisiones, Go See, experimentos y liderazgo basado en aprendizaje.
Equipos de desarrollo, QA, UX, DevOps y arquitectura
Los equipos que trabajan en productos grandes podrán entender cómo colaborar como feature teams, coordinarse sin managers de proyecto, integrar trabajo cada Sprint, elevar la Definition of Done y reducir dependencias mediante aprendizaje cruzado, código compartido, comunidades y excelencia técnica.
PMO, transformación y responsables de portfolio
Los perfiles de PMO y transformación aprenderán a diferenciar LeSS de modelos de escalado más prescriptivos. El curso les ayuda a revisar financiación, proyectos, estructura por componentes, métricas, dependencias, reporting, gestión de iniciativas y transición hacia una organización centrada en producto.
Arquitectos, líderes técnicos y responsables de calidad
Los perfiles técnicos encontrarán un enfoque profundo sobre arquitectura evolutiva, integración continua, automatización de pruebas, clean code, aceptación, Specification by Example, deuda técnica, Definition of Done común y coordinación técnica entre equipos sin crear departamentos especializados que bloqueen el flujo.
