LeSS: o Framework Large-Scale Scrum Explicado

Toda organização que ultrapassa uma equipe Scrum acaba fazendo a mesma pergunta: como coordenar dez, trinta ou oitenta equipes sem perder o que fez o Scrum funcionar desde o início? O SAFe responde adicionando estrutura: mais papéis, mais cerimônias, mais camadas para manter todos alinhados. O Large-Scale Scrum (LeSS) responde fazendo o contrário.

O LeSS é o Scrum aplicado a muitas equipes que constroem um único produto em conjunto, e chega lá reduzindo a complexidade da organização em vez de empilhar algo novo por cima dela. Em vez de perguntar como fazer agile em escala, ele parte de uma pergunta menor e mais difícil: quão simples a organização pode ficar sem deixar de ser genuinamente agile.

Fatos principais

• O Large-Scale Scrum foi moldado por Craig Larman e Bas Vodde, que trabalham juntos na escala do Scrum desde 2005.
• O less.works define dois frameworks: LeSS para 2 a 8 equipes e LeSS Huge para mais de 8, com o limite de oito equipes descrito como "apenas uma observação empírica de limite superior", e não uma regra rígida.
• O less.works nomeia dez princípios do LeSS, não nove, uma contagem que vários resumos de segunda mão erram.
• No LeSS Huge, uma Requirement Area reúne de 4 a 8 equipes por concepção, nunca menos.

O que é o LeSS (Large-Scale Scrum)?

O Large-Scale Scrum (LeSS) é o Scrum aplicado a várias equipes que constroem um único produto em conjunto, e chega lá reduzindo a complexidade da organização em vez de adicionar uma camada de coordenação por cima. Enquanto muitos frameworks de escala perguntam como fazer agile em escala, o less.works formula a pergunta do LeSS de outra maneira: como podemos simplificar a organização e ser agile, em vez de apenas cumprir os gestos.

Craig Larman e Bas Vodde construíram o framework a partir de trabalhos com clientes iniciados em 2005. Anos escalando o Scrum com organizações reais se transformaram nas regras do LeSS que o framework publica hoje. Dois frameworks saíram desse trabalho. O LeSS simples cobre de 2 a 8 equipes. O LeSS Huge assume a partir daí, para mais de 8. O less.works é franco ao dizer que o limite de oito equipes não é uma regra rígida, chamando-o de "apenas uma observação empírica de limite superior", o ponto em que eles viram a estrutura menor começar a precisar de ajuda, e não um número embutido na lógica do framework.

Os dois frameworks mantêm os mesmos pontos inegociáveis: um Product Backlog, uma Definition of Done, um Sprint, um Product Owner e um Incremento de Produto potencialmente entregável, não importa quantas equipes contribuam para ele.

Os dez princípios do LeSS

O less.works é explícito quanto à contagem: dez princípios, não nove. Isso confunde as pessoas porque um bom número de resumos de segunda mão arredonda para nove, deixando um de fora no caminho. A distinção importa menos como curiosidade e mais porque essas são as ideias das quais as regras do LeSS realmente vêm. O less.works diz que os princípios "nos guiaram na criação do LeSS" e que devem guiar uma implementação da mesma forma: são aquilo a que você recorre quando surge uma situação que as regras não cobrem.

Vale refletir sobre esse último princípio se você já passou um tempo no SAFe ou em outro framework que se apoia em fluxos de trabalho paralelos: a teoria das filas diz que adicionar mais trabalho em andamento deixa tudo mais lento, mesmo quando parece que mais esforço paralelo deveria acelerar. O LeSS aplica essa lógica à organização inteira, não apenas ao quadro de uma equipe.

LeSS vs LeSS Huge: o que realmente muda a partir de oito equipes

De duas a oito equipes é onde vive o LeSS simples, e nesse intervalo nada muda estruturalmente na coordenação: um Product Backlog, um Product Owner trabalhando diretamente com todas as equipes, um Sprint. A partir de oito equipes, o LeSS Huge acrescenta a estrutura necessária para manter uma visão do produto como um todo quando nenhum Product Owner consegue acompanhar sozinho, de forma plausível, o trabalho diário de todas as equipes.

Os Area Product Owners se especializam na sua área e atuam como Product Owners para as equipes dentro dela, mas o Product Owner geral mantém a palavra final sobre o backlog e a visão de todo o produto. Os dois se sincronizam constantemente, especificamente antes do Sprint Planning, para que as prioridades locais de um Area PO nunca se afastem muito do que o Product Owner geral decidiu ser mais importante. Esse ponto de coordenação é onde o LeSS Huge justifica sua complexidade extra: ele existe para proteger o foco no produto como um todo quando o número de equipes ultrapassa o que uma única pessoa consegue acompanhar.

O Sprint do LeSS: um Sprint, muitas equipes

Conceitualmente, o LeSS roda um único Sprint no nível do produto para o produto inteiro, e não um Sprint por equipe no seu próprio relógio. Todas as equipes começam e terminam juntas, e o resultado é um Incremento de produto integrado e potencialmente entregável, e não uma pilha de incrementos por equipe que alguém precisa reconciliar depois. O Sprint Planning de todas as equipes acontece ao mesmo tempo, assim como a Sprint Review e a retrospectiva. O que não precisa estar alinhado é o refinamento do backlog: as equipes podem refinar no seu próprio ritmo, desde que os itens estejam prontos quando o Sprint Planning começar.

O próprio Sprint Planning se divide em duas partes, como no nível de uma única equipe, só que com mais gente na sala na primeira metade.

O refinamento é onde o LeSS exige mais disciplina, já que é fácil deixá-lo escorregar quando nada o obriga a entrar no calendário como acontece com o Sprint Planning. O less.works chama a versão multiequipe de "possivelmente o evento mais importante do LeSS", e as equipes normalmente gastam algo como um décimo da capacidade do Sprint nele. Se você o pular, o Sprint Planning One vira uma reunião gasta esclarecendo em vez de selecionando, o oposto do seu propósito.

A Sprint Review merece menção própria, porque é fácil conduzi-la como uma demo de uma única equipe apenas esticada para mais pessoas. O LeSS a trata como um ponto genuíno de inspeção e adaptação sobre o produto inteiro, e não como um portão de aprovação do Product Owner, uma distinção mais sutil do que parece. Uma demo que na verdade é um checkpoint de aprovação treina as equipes a se apresentarem para o PO. Um bazar que deixa os stakeholders circular, fazer perguntas e moldar o que acontece a seguir treina a organização a realmente olhar para o produto que construiu.

Um Product Owner para o produto inteiro (a parte de que todos duvidam)

Este é o detalhe que deixa a maioria das pessoas sem reação na primeira vez que o ouvem: um Product Owner para o produto inteiro, em todas as equipes, não importa quantas sejam. Parece um gargalo à espera de acontecer. Na prática, o LeSS faz a conta fechar sendo preciso sobre o que o Product Owner realmente precisa fazer.

Isso deixa o Product Owner totalmente fora do Sprint Planning Two, das Daily Scrums e das retrospectivas das equipes. Essas reuniões pertencem às equipes, não ao PO. O LeSS consegue isso separando duas tarefas que muitas organizações juntam em um único papel: priorização e esclarecimento. O Product Owner é dono da priorização, decidindo o que mais importa e por quê. O esclarecimento, a conversa de ida e volta sobre como exatamente um item deve se comportar, acontece diretamente entre a equipe e o cliente ou stakeholder, com o PO disponível, mas não obrigatório como intermediário. O less.works descreve o papel pretendido como "um conector, não um intermediário", um trabalho significativamente diferente de ser o único canal aprovado para toda pergunta que uma equipe tem.

É também um formato diferente do que muitos leitores supõem ao chegar. Isto não é um Product Manager acima de vários Product Owners, coordenando uma equipe de coordenadores. É uma pessoa fazendo o trabalho do Product Owner do Scrum, em escala de produto, com as partes específicas do trabalho que não escalam repassadas às equipes.

Essa divisão também protege a autonomia das equipes de uma forma fácil de perder de vista. Se toda pergunta de esclarecimento tivesse de passar por uma só pessoa, o LeSS recriaria exatamente o gargalo que os críticos supõem que ele tem. Em vez disso, equipes que podem falar diretamente com os clientes andam mais rápido nos detalhes, e o Product Owner gasta o tempo liberado naquilo que só uma pessoa pode fazer pelo produto inteiro: decidir o que será construído a seguir. Se você está comparando esse papel com o trabalho de coordenação que um Scrum Master faz no nível da equipe, a divisão é a mesma que já existe no Scrum de uma única equipe, apenas aplicada a mais equipes em vez de dentro de uma.

LeSS vs SAFe: reduzir a escala vs adicionar estrutura

Os leitores chegam a esta página geralmente depois de já terem lido sobre o SAFe, e a forma justa de compará-los é dizer o que cada um realmente otimiza. O SAFe mantém as equipes mais ou menos como estão e adiciona camadas, papéis e uma cadência de planejamento em escala para coordená-las. O LeSS vai na direção oposta: pede que a organização se reorganize em torno de feature teams, elimine papéis extras e coordene por meio de um Sprint e um Backlog em vez de uma pilha de eventos de planejamento.

Nenhum lado dessa tabela está errado, e nenhum dos frameworks é mais agile do que o outro por alguma medida objetiva. Eles resolvem o mesmo problema de coordenação com instintos opostos: o SAFe supõe que a coordenação precisa de mais andaimes, e o LeSS supõe que a maior parte desses andaimes é o problema que ele tenta resolver. Onde o SAFe usa o PI Planning como evento de sincronização, o LeSS usa o Sprint Planning One, o mesmo evento que uma única equipe já realiza, só que com todas as equipes na sala. Essa é a diferença filosófica em uma única comparação: um framework criou um evento novo para lidar com a escala, o outro escalou o evento que já tinha.

LeSS vs modelo Spotify vs Scrum multiequipe simples

Mais duas comparações aparecem com frequência suficiente para serem cobertas brevemente. Nenhuma delas é de fato concorrente do LeSS como o SAFe é, já que resolvem problemas ligeiramente diferentes.

O modelo Spotify nunca foi feito para ser copiado por inteiro, e a própria Spotify foi além da estrutura original anos atrás. Ele viaja bem como vocabulário (squads, chapters, guilds), mas mal como livro de regras, porque nunca publicou um. O Scrum multiequipe simples, várias equipes rodando o Scrum padrão sem framework compartilhado por cima, é o que a maioria das organizações faz por padrão antes de adotar qualquer outra coisa, e costuma ser o que quebra primeiro: nada impede que os Product Owners de duas equipes priorizem em direções opostas, porque nada amarra seus backlogs desde o início. O LeSS é, em um sentido real, o que você obtém ao pegar essa configuração padrão e corrigir a coisa específica que a quebra: um Backlog, um Dono, um Sprint. Há uma resposta mais antiga para a mesma pergunta que vale conhecer: a Crystal escala trocando por um membro mais pesado de uma família de metodologias conforme a equipe cresce, em vez de manter um framework e reorganizar a organização em torno dele.

A realidade da adoção: o que uma adoção do LeSS realmente exige

O SAFe vende mais fácil, e vale dizer claramente por quê. Uma implantação do SAFe adiciona coisas: novos papéis, um currículo de treinamento, certificações, um evento nomeado no calendário. Parece progresso em um organograma, mesmo antes de entregar qualquer coisa. Uma adoção do LeSS remove coisas, e remoção é uma história muito mais difícil de contar a uma sala cheia de gestores cujo cargo atual pode ser uma das coisas que vão sair.

Nada disso é sutil. Reorganizar em torno de feature teams normalmente significa que o trabalho de algumas pessoas muda de forma, e consolidar a responsabilidade pelo produto em um só papel normalmente significa que os cargos de outras pessoas desaparecem ou são redefinidos. É uma exigência genuinamente diferente da do SAFe, que na maior parte treina pessoas em novos papéis em vez de remover papéis que já existem. É também parte do motivo pelo qual as adoções do LeSS tendem a ser menores e mais lentas para se espalhar do que as implantações do SAFe. Menos organizações estão dispostas a ter essa conversa com a própria estrutura de gestão, mesmo quando o argumento de fundo para reduzir a escala é sólido.

O LeSS tende a servir organizações que já rodam bem o Scrum de uma equipe e têm um backlog real para mostrar, não aquelas que ainda estão aprendendo o que um Sprint ou uma Definition of Done significam no dia a dia. Serve também a organizações dispostas a nomear um Product Owner com autoridade real sobre o produto inteiro e dispostas a se reorganizar em torno de feature teams em vez de defender a estrutura de equipes de componente que já têm. Não serve a organizações que precisam da estrutura de relatórios e papéis que um ambiente regulado ou fortemente contratual exige, nem às que gerenciam vários produtos genuinamente separados que não compartilham um backlog desde o início. Esses casos costumam se encaixar melhor na camada de portfólio do SAFe ou em um modelo totalmente diferente.

Quando não usar o LeSS

Nenhum desses motivos faz do LeSS um framework ruim. São motivos pelos quais uma organização específica, em um momento específico, pode não estar pronta para o que ele pede. A versão honesta dessa frase vale também para o SAFe ou qualquer abordagem de escala: o framework não é a parte difícil. Mudar a estrutura real de uma organização é, e isso é verdade quer o framework adicione andaimes ou os retire.

O LeSS não é a venda mais fácil, e nunca tentou ser. Se a sua organização já roda bem o Scrum de uma equipe e está disposta a se reorganizar em torno de feature teams e de um único Product Owner, reduzir a escala é uma opção real, não apenas uma postura filosófica. Se ela ainda não está disposta a isso, o SAFe ou uma abordagem mais leve provavelmente levará mais longe e mais rápido, e essa também é uma resposta legítima. A escolha não é sobre qual framework é mais agile. É sobre qual direção de mudança a sua organização consegue de fato fazer.