O Scrum foi pensado para um time pequeno. O Guia do Scrum fala em times de, em geral, 10 pessoas ou menos. Quando o produto cresce e o trabalho passa a exigir 30, 50 ou 80 pessoas, a pergunta deixa de ser "como fazer Scrum" e passa a ser "como vários times fazem Scrum no mesmo produto sem pisar uns nos outros". É disso que trata o Scrum em escala.
O próprio guia dá a regra de partida: se o time ficar grande demais, deve considerar se reorganizar em vários times Scrum coesos, focados no mesmo produto, e por isso esses times devem compartilhar a mesma Meta do Produto, o mesmo Product Backlog e o mesmo Product Owner. Quando há vários times no mesmo produto, eles também precisam definir juntos e seguir a mesma Definição de Pronto. O guia para aí. Como os times planejam juntos, resolvem dependências e integram o trabalho fica a cargo de práticas complementares.
As três respostas mais conhecidas para essa lacuna são o Scrum of Scrums (formalizado no Scrum@Scale), o Nexus e o LeSS. Abaixo está como cada uma funciona, o que acrescenta ao Scrum e quando faz mais sentido.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
Os problemas que aparecem com vários times
Antes de escolher um framework, vale reconhecer os sintomas. Em produtos com vários times Scrum, os problemas mais comuns são:
- Dependências descobertas tarde. O time A só percebe no meio da Sprint que precisa de algo do time B.
- Integração no fim. Cada time termina o seu incremento, mas o produto integrado só é testado perto da entrega.
- Vários backlogs. Cada time tem o seu, e ninguém consegue dizer qual é a prioridade do produto.
- Definições de pronto diferentes. Um time considera pronto o que passou em teste unitário; outro, o que está em homologação.
- Product Owner sobrecarregado ou multiplicado. Ou um PO não dá conta de sete times, ou cada time ganha seu PO e o produto perde a visão única.
Os três frameworks atacam esses problemas com doses diferentes de estrutura.
Scrum of Scrums e o Scrum@Scale
O Scrum of Scrums é a prática mais antiga e mais simples: representantes de cada time se reúnem com frequência para tratar dependências e impedimentos que atravessam os times. Por muito tempo foi só uma reunião, sem regras definidas. Jeff Sutherland, cocriador do Scrum, a formalizou no Scrum@Scale, cujo guia (versão 2.1, de fevereiro de 2022) é publicado pela Scrum Inc.
No Scrum@Scale:
- Scrum of Scrums (SoS): um time maior, formado por vários times Scrum, que funciona como um time Scrum em escala e responde por um conjunto integrado de incrementos ao fim de cada Sprint. O guia aponta 4 ou 5 times como número ótimo num SoS.
- Scaled Daily Scrum: evento com timebox de até 15 minutos, com pelo menos um representante de cada time, para coordenar o trabalho e tratar impedimentos.
- Scrum of Scrums Master: o Scrum Master do SoS, que garante os eventos em escala e responde pela entrega conjunta.
- Chief Product Owner: coordena as prioridades com o time de Product Owners e mantém um único backlog ordenado.
- Executive Action Team (EAT) e Executive MetaScrum: fóruns de liderança. O EAT exerce o papel de Scrum Master para a organização inteira e remove impedimentos que os times não conseguem remover; o Executive MetaScrum é onde a liderança negocia prioridades com o time de Product Owners, pelo menos uma vez por Sprint.
O Scrum@Scale se apresenta como uma arquitetura livre de escala: grupos de SoS podem se reunir em camadas maiores com a mesma lógica. É uma boa escolha quando a organização quer partir do Scrum que já conhece e ir acrescentando camadas conforme cresce.
Nexus
O Nexus foi criado por Ken Schwaber, cocriador do Scrum, e é mantido pela Scrum.org. O Nexus Guide (edição de janeiro de 2021) o descreve como um grupo de cerca de três a nove times Scrum trabalhando juntos num único produto.
O Nexus acrescenta ao Scrum:
- Nexus Integration Team: formado pelo Product Owner, por um Scrum Master e por membros que muitas vezes também pertencem aos times. Responde por garantir que um Incremento Integrado e pronto seja produzido pelo menos uma vez por Sprint. Um detalhe importante: ele não faz a integração; quem integra são os próprios times.
- Eventos em escala: refinamento entre times (para expor e reduzir dependências), Nexus Sprint Planning, Nexus Daily Scrum (focada em problemas de integração e no progresso em direção à Meta da Sprint do Nexus), Nexus Sprint Review e Nexus Sprint Retrospective.
- Artefatos e compromissos: um único Product Backlog com a Meta do Produto; um Nexus Sprint Backlog com a Meta da Sprint do Nexus; um Incremento Integrado com uma Definição de Pronto que todos os times seguem.
Uma regra que surpreende: a Nexus Sprint Review substitui as Reviews individuais dos times, porque o feedback das partes interessadas deve ser sobre o produto integrado, e não sobre partes.
O Nexus é a extensão mais "fiel" ao Guia do Scrum e funciona bem para quem já usa o vocabulário e as certificações da Scrum.org.
LeSS (Large-Scale Scrum)
O LeSS foi criado por Craig Larman e Bas Vodde a partir do trabalho conjunto que começaram em 2005. A filosofia está no nome: menos (less) papéis, menos artefatos e menos processo. Os autores defendem que acrescentar muitas regras e depois pedir à organização que as corte é um caminho errado; melhor começar com o mínimo.
O site oficial (less.works) descreve duas variantes:
- LeSS: até oito times de até oito pessoas cada.
- LeSS Huge: para produtos com até alguns milhares de pessoas, dividindo o produto em áreas de requisitos.
Em ambos, há um único Product Owner, um único Product Backlog, uma única Definição de Pronto e uma única Sprint para todos os times, que entregam um incremento único do produto. Os eventos mudam assim:
- Sprint Planning One: pessoas de todos os times decidem como dividir os itens do backlog e identificam trabalho compartilhado.
- Sprint Planning Two: cada time planeja o seu trabalho, em geral em paralelo.
- Refinamento: obrigatório em cada time; o refinamento com vários times é uma variação comum.
- Sprint Review: com todos os times, clientes e partes interessadas, muitas vezes no formato de feira, com estações por tema.
- Overall Retrospective: retrospectiva específica do LeSS, focada em melhorar o sistema como um todo.
O LeSS não cria um time de integração nem um papel de coordenação: os times coordenam diretamente entre si. Isso exige times multifuncionais de verdade, organizados por funcionalidade do cliente, e não por componente técnico.
Comparação lado a lado
| Critério | Scrum@Scale (Scrum of Scrums) | Nexus | LeSS |
|---|---|---|---|
| Quem criou | Jeff Sutherland (Scrum Inc.) | Ken Schwaber (Scrum.org) | Craig Larman e Bas Vodde |
| Tamanho indicado | 4 ou 5 times por SoS, organizados em camadas | Cerca de 3 a 9 times | Até 8 times; LeSS Huge para muito mais |
| Product Owner | Time de POs com um Chief Product Owner | Um Product Owner | Um Product Owner (com Area POs no LeSS Huge) |
| Papel novo de integração | Scrum of Scrums Master | Nexus Integration Team | Nenhum |
| Review | Por SoS, com produto integrado | Uma Nexus Sprint Review única | Uma Sprint Review com todos os times |
| Envolve a liderança | Sim, com EAT e Executive MetaScrum | Pouco | Pede mudança organizacional profunda |
| Melhor para | Organizações que querem crescer por camadas | Times que já seguem o Guia do Scrum à risca | Organizações dispostas a simplificar a estrutura |
Para organizações com dezenas de times e necessidade de ligar o trabalho ao portfólio e ao orçamento, a alternativa mais estruturada é o SAFe. Para quem prefere escolher práticas caso a caso, o Disciplined Agile oferece um ciclo de vida próprio para times de times.
Como escolher a abordagem de escala
- Confirme que precisa escalar. Muitos problemas de "escala" são de arquitetura ou de backlog. Se os times podem ser reorganizados para entregar com pouca dependência entre si, coordenação leve basta.
- Conte os times que trabalham no mesmo produto. Dois ou três times costumam se virar com refinamento conjunto e uma Daily de representantes. Acima disso, um framework ajuda.
- Veja quem decide a prioridade. Se cada time tem um "dono" diferente e ninguém quer abrir mão, nenhum framework resolve sem uma decisão da liderança sobre o Product Owner único.
- Avalie a disposição para mudar a estrutura. O LeSS pede times por funcionalidade e menos camadas de gestão. O Nexus e o Scrum@Scale permitem começar com menos mudança.
- Comece pequeno e inspecione. Aplique o framework escolhido em um produto, avalie por alguns ciclos e só depois expanda.
Erros comuns ao escalar o Scrum
- Um backlog por time. É o erro que mais destrói a visão do produto. Vários times, um backlog.
- Times por componente. Um time de banco de dados, um de telas e um de integração geram dependência em todo item. Prefira times que entregam funcionalidades de ponta a ponta.
- Scrum of Scrums como reunião de status. Representantes relatando o que cada time fez não resolvem nada. O foco é dependência e impedimento.
- Definição de Pronto diferente por time. O Guia do Scrum exige uma única para o produto.
- Escalar antes de fazer Scrum bem em um time. Escala multiplica o que já existe, inclusive os problemas.
Quando os times trabalham em fluxo contínuo em vez de Sprints, a coordenação segue outra lógica, descrita em Kanban para múltiplos times. E para quem quer olhar a estrutura de times por outro ângulo, o modelo Spotify mostra uma forma de organizar autonomia e especialidades.
Por onde começar
Desenhe o mapa dos times que trabalham no seu produto: quem depende de quem, onde o trabalho é integrado e quem decide a prioridade. Esse desenho mostra qual dos problemas acima é o seu e qual abordagem ataca melhor. O guia completo de métodos ágeis e Scrum traz a base que todos os times precisam compartilhar antes de qualquer escala.
Para visualizar como as entregas dos vários times se encaixam ao longo dos próximos ciclos, o roadmap de programa da Projeto Diário ajuda a montar uma visão única de marcos, entregas e dependências entre times, um ótimo insumo para o primeiro planejamento conjunto.
