O que é LeSS (Large-Scale Scrum)?

Craig Larman e Bas Vodde desenvolveram e documentaram LeSS a partir de experiências com desenvolvimento de produto em múltiplos times. O framework e suas regras estão publicados no site oficial less.works. As regras de 2024 descrevem LeSS básico para dois a oito times e LeSS Huge para oito ou mais, com estrutura adicional. O Scrum Guide continua sendo a referência para Scrum; LeSS é um framework de escala com regras próprias.

LeSS leva a lógica de um Scrum para vários times que criam um produto. A pergunta principal não é como multiplicar cerimônias, mas como fazer grupos diferentes inspecionarem um mesmo produto e se adaptarem juntos. Segundo as regras oficiais, o LeSS básico se aplica a produtos com dois a oito times. LeSS Huge atende um conjunto maior e acrescenta áreas de requisitos. O número de times, porém, não basta para decidir a adoção: é necessário verificar se realmente há um produto e uma direção compartilhada.

Um produto, uma prioridade. No LeSS básico, há um Product Owner e um Product Backlog para o produto. Isso evita que cada time otimize uma lista isolada sem saber o que tem maior valor para o cliente. O Product Owner não precisa detalhar sozinho todo o trabalho; conversa com times e interessados. Se o produto for artificialmente definido apenas para caber num organograma, a lista única pode esconder diferenças relevantes. A definição de produto é uma decisão de gestão essencial.

Times capazes de entregar. O framework privilegia times duradouros, multifuncionais e focados em funcionalidades completas, em vez de separar cada componente num departamento. Uma solicitação que exige passar sequencialmente por várias equipes tende a criar filas. A mudança exige desenvolvimento de competências e colaboração técnica. Não se resolve renomeando equipes como times de produto enquanto permissões, arquitetura e incentivos mantêm as mesmas dependências.

Uma Sprint e um incremento. Os times trabalham numa Sprint comum e buscam um incremento integrado do produto. A Definition of Done compartilhada ajuda a evitar que “pronto” tenha significados incompatíveis. Integração frequente e testes são importantes porque o problema da escala não desaparece no fim do ciclo. Se cada time demonstra uma parte que ainda não funciona com as outras, a organização tem vários avanços locais, mas não um incremento utilizável.

Planejamento conjunto e local. A Sprint Planning inclui uma parte com representantes dos times e Product Owner para entender a prioridade e distribuir itens, seguida de planejamento pelos times. O refinamento pode reunir pessoas de vários times quando isso ajuda a compartilhar conhecimento, além do trabalho em cada time. A Daily Scrum é realizada por time; coordenação entre grupos acontece quando o trabalho exige. Criar uma reunião permanente para qualquer detalhe pode trocar dependências técnicas por dependências de calendário.

Inspeção do produto. A Sprint Review é voltada ao produto, com interessados e times examinando o incremento e adaptando o backlog. As retrospectivas de time permitem discutir problemas próximos; uma retrospectiva geral de LeSS olha obstáculos do sistema que atravessam times. Não faz sentido pedir que apenas um time resolva sozinho uma política de contratação, uma plataforma difícil de integrar ou um incentivo que empurra filas para outro grupo.

LeSS Huge. Quando o conjunto de times cresce, as regras oficiais definem áreas de requisitos, cada uma com Area Product Owner, mantendo um Product Owner geral, um Product Backlog conceitual e uma Sprint de produto. A forma maior não é um atalho para a menor. Ela adiciona estrutura para lidar com escala e também custo de coordenação. Antes de adotá-la, vale perguntar se o produto pode ser simplificado ou se grupos menores atenderiam melhor públicos diferentes.

Organização e liderança. LeSS explicita que escalar trabalho envolve desenho organizacional. A liderança precisa dar espaço para times resolverem dependências e remover políticas que inviabilizam entrega de ponta a ponta. Isso pode mudar papéis, especializações e mecanismos de decisão. A intenção não é abolir gestão; é direcionar gestão para melhorar o sistema. Uma implantação imposta sem participação dos profissionais costuma gerar o mesmo processo anterior com novos nomes.

Relação com outros caminhos. SAFe, Scrum of Scrums, Team Topologies e LeSS abordam aspectos diferentes de coordenação e escala. Nenhum se torna adequado só porque a organização é grande. Compare produto, dependências, capacidade técnica e custo de mudança. LeSS se distingue pela tentativa de manter poucos elementos adicionais e aproximar todos do produto inteiro, mas isso exige mudanças organizacionais reais.

Imagine uma empresa hipotética com quatro times construindo a mesma plataforma. Antes, cada time mantém sua própria lista; uma funcionalidade de cadastro passa por três equipes e só é integrada no fim do mês. Em 20 pedidos recentes, o tempo mediano entre começar e disponibilizar é de 32 dias. Esses números são ilustrativos. A liderança escolhe experimentar uma direção única de produto, times com competências mais amplas e integração frequente.

No novo arranjo, há um backlog priorizado pelo Product Owner. Na Sprint Planning conjunta, representantes discutem dependências e selecionam trabalho que possa produzir um incremento integrado. Durante a Sprint, times conversam diretamente quando aparece uma dependência, e a Review mostra o produto funcionando, não apresentações isoladas. Após alguns ciclos, 20 pedidos comparáveis têm mediana de 23 dias. A equipe ainda verifica defeitos, satisfação e diferenças no tipo de item antes de atribuir o resultado à mudança.

O ganho principal não é ter uma cerimônia a mais. Antes, prioridades e critérios de pronto variavam entre times; depois, há uma direção e um incremento examinável. Se arquitetura ou aprovações continuarem separando componentes, apenas copiar a agenda de LeSS não produzirá o mesmo resultado. O exemplo mostra uma hipótese organizacional a testar, não promessa de redução de prazo.

Curso K21 recomendado