Como o framework de escalabilidade da Scrum.org estende minimamente o Scrum para que várias Scrum Teams reduzam dependências entre times, integrem continuamente um único produto e preservem o empirismo - sem confundir Nexus com o Scrum básico.
Tempo estimado de leitura: 25 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender o que é o , de onde ele surgiu, sua relação com a .org e com o , o problema de escalabilidade que ele procura resolver, como aproximadamente três a nove Teams cooperam em torno de um único produto e de um único , por que dependências e integração são centrais para o framework, pelo que o é accountable e quais eventos, artefatos e compromissos adicionais existem no em alto nível.
Introdução: o existe porque adicionar times cria um novo tipo de complexidade
Uma única consegue inspecionar diretamente o próprio trabalho. Com cinco Teams, porém, o produto pode falhar mesmo quando cada time, individualmente, parece bem-sucedido.
O se adapta a uma escala surpreendentemente ampla por meio de seu desenho básico. Um produto tem um , um , um , uma e Teams pequenas, autogerenciáveis e coesas. Se uma equipe se tornar grande demais, o Scrum Guide afirma que ela deve considerar reorganizar-se em várias Teams coesas, concentradas no mesmo produto.
Entretanto, várias equipes criam um novo sistema. A Team A depende de uma API da Team B. A Team C altera um modelo de dados compartilhado. A Team D descobre que seu trabalho concluído é incompatível com as premissas da Team A. A integração ocorre tarde; assim, todos os times relatam progresso enquanto o do produto permanece inutilizável.
Essas falhas não são necessariamente causadas por uma aplicação fraca do dentro de cada time. Elas emergem das interações entre os times. Dependências, caminhos de coordenação, riscos de integração, infraestrutura compartilhada e interpretações inconsistentes criam uma complexidade que não existia na mesma escala anteriormente.
O foi criado para lidar com esse problema alterando o mínimo possível do . Ken Schwaber, cocriador do e fundador da .org, desenvolveu o framework com a .org e publicou o primeiro Guide em 2015. O Guide foi atualizado em 2018 e novamente em 2021 para se alinhar ao Scrum Guide de 2020.
A .org descreve o como uma extensão mínima do para aproximadamente três a nove Teams que trabalham juntas em um único produto. Um possui um único e um único . Seu propósito é ajudar esses times a reduzir a complexidade causada por dependências entre equipes, para que consigam produzir um Integrated valioso, útil e integrado pelo menos uma vez a cada .
Esse enquadramento é essencial. não é " 2.0" e não substitui o Scrum Guide. O continua sendo a base. O acrescenta accountabilities, eventos, artefatos e regras somente onde o trabalho de múltiplos times cria problemas que as estruturas de uma única não coordenam explicitamente.
Para a , o é conhecimento complementar. Questões sobre básico devem continuar sendo respondidas com base no Scrum Guide. Conceitos específicos do , como ,,, Cross-Team Refinement ou , não devem ser importados para o comum, a menos que o contexto diga explicitamente que se trata de .
A lição mais profunda vai além da certificação. A escalabilidade não falha principalmente porque as organizações precisam de mais reuniões. Ela falha porque o trabalho local deixa de se integrar em um único produto transparente. O coloca esse problema no centro.
O que é ?
Um é um grupo de aproximadamente três a nove Teams que trabalham juntas para entregar um único produto.
A palavra significa conexão ou relação. O framework usa essa ideia literalmente: ele conecta várias Teams cujo trabalho precisa se transformar em um único do produto.
Todas as continuam valendo. Os times são multifuncionais e autogerenciáveis. O continua sendo uma única pessoa. A ordenação do continua sendo feita no nível do produto. O trabalho não faz parte de um se não atender à .
O então acrescenta apenas a estrutura necessária para tornar mais transparentes as dependências entre times, o trabalho de integração e o progresso em nível de produto.
em uma frase
é o framework da .org para escalar entre aproximadamente três e nove Teams que trabalham a partir de um único para produzir um único Integrated .
Figura 1. O preserva o e acrescenta uma camada fina para lidar com dependências entre times e com a complexidade de integração.
e .org
O foi desenvolvido por Ken Schwaber e pela .org. A .org mantém o Guide e os recursos de aprendizagem, avaliações e treinamentos de Scaled associados ao framework.
O primeiro Guide público foi lançado em 2015. Uma atualização em 2018 trouxe maior clareza sobre integração, accountability do e o significado de Done em escala. A revisão de 2021 alinhou a terminologia e a estrutura do ao Scrum Guide de 2020, incluindo , autogerenciamento, accountabilities e um estilo de redação menos prescritivo.
O é gratuito para uso, e o Guide está disponível publicamente. Assim como o Scrum Guide, ele define o framework em vez de tentar prescrever todas as práticas de implementação.
Essa relação é importante porque o deve ser entendido por meio do framework oficial da .org, e não como um sinônimo genérico de " em escala".
Período
Desenvolvimento
Significado
Início da década de 1990
O surge para o desenvolvimento de produtos complexos
Times pequenos e coesos, e entrega iterativa/incremental
2015
A .org lança o
Extensão formal e mínima para várias Teams trabalhando em um produto
Uma não ganha um apenas porque utiliza . Cross-Team Refinement não é um evento obrigatório do . O não é um dos três . O não é um dos três compromissos básicos do .
Esses elementos existem apenas quando o é aplicado intencionalmente.
Essa distinção protege o raciocínio para o exame. Se uma questão da perguntar o que acontece no , responda de acordo com o . Não introduza ou um , a menos que a questão descreva explicitamente o .
Elemento
Framework
Status
Obrigatório
Obrigatório
Obrigatório
Obrigatório
Extensão do
Somente ao usar
Cross-Team Refinement
Extensão do
Obrigatório no ; não é evento do
Extensão do
Somente ao usar
Extensão do
Somente ao usar
Extensão do
Somente ao usar
Limite para o exame
O estende o . Ele não modifica o que conta como básico no Scrum Guide.
O problema que o foi projetado para resolver
Uma única possui um sistema interno de comunicação e um . Com vários times, o sistema do produto passa a conter muitas interações possíveis entre equipes.
A principal fonte de complexidade adicional é a dependência. Um time pode não conseguir concluir seu trabalho até que outro tome uma decisão, exponha um serviço, altere um componente, prepare dados ou integre uma interface.
Dependências provocam espera. A espera aumenta o e a incerteza das previsões. Também cria risco de integração, pois uma alteração localmente correta pode falhar quando combinada ao trabalho de outro time.
Por isso, o framework concentra-se na transparência que ajuda os times a detectar, minimizar e remover dependências o mais cedo possível.
É útil pensar no menos como "mais " e mais como "um sistema que torna difícil esconder o acoplamento entre múltiplos times".
Problema de escalabilidade
Exemplo
Dependência de PBI entre times
A Team A não consegue concluir até que a Team B altere uma API
Dependência técnica compartilhada
Vários times disputam um mesmo especialista ou ambiente
Dependência de integração
As alterações funcionam isoladamente, mas falham quando combinadas
Dependência de decisão
Os times precisam alinhar arquitetura, contratos ou comportamento do produto
Fragmentação do feedback
Stakeholders inspecionam saídas separadas dos times em vez de um produto integrado
Várias Teams - um único produto
O parte da premissa de um único produto. Aproximadamente três a nove Teams trabalham juntas nesse produto.
Há um e um . As Teams puxam trabalho desse mesmo .
Isso evita que o framework se transforme em uma hierarquia de Product Owners por time e backlogs por time competindo por recursos. O valor do produto continua sendo ordenado no nível do produto.
Os times continuam sendo Teams. O não os transforma em subequipes de uma gigantesca "superequipe". Cada uma continua usando e autogerenciando seu próprio trabalho, enquanto coordena aquilo que dependências e integração exigem.
Figura 2. Estrutura de alto nível do : um sistema de produto com várias Teams e uma camada mínima de integração.
Dependências são o sinal de escalabilidade
No , o gerenciamento de dependências não se resume a criar um rastreador de dependências cada vez mais sofisticado. A direção desejada é reduzir dependências.
Cross-Team Refinement ajuda os times a detectar dependências antes do . Os times podem mudar a forma como o trabalho é decomposto, compartilhar competências, reordenar PBIs, ajustar qual time provavelmente selecionará determinado trabalho, alterar contratos técnicos ou colaborar diretamente para reduzir o acoplamento.
Algumas dependências não podem ser removidas imediatamente. Ainda assim, torná-las visíveis é valioso, porque o pode planejar a integração deliberadamente e se adaptar quando o risco mudar.
A medida de saúde no longo prazo é se o se torna melhor em entregar valor integrado com menos restrições entre times.
Integração: o coração do
Integração é o segundo conceito central do . Vários times podem concluir trabalhos locais e ainda assim não criar um produto utilizável.
Por isso, o Guide se concentra em um Integrated . O trabalho combinado do deve se integrar ao produto existente e atender à .
A integração deve ocorrer continuamente. Se os times esperarem até o último dia da para combinar seus trabalhos, a integração se transforma em uma fase oculta e a transparência chega tarde demais.
A integração frequente pode revelar APIs incompatíveis, premissas inconsistentes de dados, migrações conflitantes, problemas de segurança, restrições de ambientes compartilhados e diferenças na interpretação da qualidade enquanto ainda há tempo para adaptação.
Princípio do
Uma coleção de entregas localmente concluídas pelos times não é o objetivo. O existe para ajudar essas saídas a se tornarem um único Done Integrated .
O
O , normalmente abreviado como , é a accountability adicional do que não existe no básico.
O inclui o , um e Members. As pessoas envolvidas também podem participar de uma ou mais Teams, conforme apropriado.
O é accountable por assegurar que um Done Integrated seja produzido pelo menos uma vez a cada . Seu foco não é executar todo o trabalho de integração por conta própria. Isso centralizaria a responsabilidade e criaria um novo silo.
Em vez disso, o coordena, orienta e cria transparência para que as preocupações de integração sejam tratadas em todo o . Ele presta atenção às dependências entre times, às práticas de integração, à aplicação do e ao funcionamento do em todo o .
Um erro comum é tratar o como um escritório de gerenciamento de projetos ou como um centro de comando. Ele não deve atribuir trabalho aos times nem substituir o autogerenciamento.
Componente do
Propósito em alto nível
Mantém a accountability pelo valor no nível do produto e pelo único
Apoia o uso eficaz de / e a melhoria sistêmica
Members
Trazem habilidades, conhecimentos e atenção relevantes para integração
como um todo
Accountability por viabilizar um Done Integrated pelo menos a cada
Atenção sobre o
O é accountable pelos resultados de integração; ele não é um departamento central de integração que retira das Teams a responsabilidade pela integração.
Cross-Team Refinement
é uma atividade contínua no , não um evento formal do . O torna o Cross-Team Refinement um evento formal do porque a descoberta de dependências entre times é central para a escalabilidade.
Durante o Cross-Team Refinement, o melhora o entendimento dos Items entre os times, decompõe o trabalho o suficiente para compreender a provável entrega e identifica dependências.
Os participantes podem explorar quais times estão mais bem posicionados para trabalhar em determinados PBIs, como o sequenciamento pode reduzir dependências e qual conhecimento precisa circular entre as equipes.
O objetivo não é prever todas as dependências com meses de antecedência. O trabalho complexo continuará revelando incógnitas. O evento melhora a transparência de curto prazo para que o possa planejar com evidências melhores.
O coordena o trabalho de todas as Teams para a próxima , preservando ao mesmo tempo as responsabilidades de de cada time.
O cria um alinhado ao e que expressa o propósito que o pretende alcançar durante a .
Cada também cria seu próprio alinhado ao e seu próprio .
O combinado torna visíveis o trabalho do e as dependências entre times.
O framework não exige uma única conversa gigantesca de planejamento para todos os detalhes. O propósito é fornecer coordenação suficiente para tornar possível uma integrada.
O existe para inspecionar o progresso em direção ao e identificar impactos e dependências entre times que exigem adaptação.
Ele não substitui o de cada . Os times continuam inspecionando e adaptando seus próprios Backlogs.
O concentra-se nas informações que importam além dos limites de um único time: status da integração, dependência recém-descoberta, alteração de interface, risco de ambiente compartilhado ou outro impacto no nível do produto.
A comunicação entre times não fica restrita a esse evento. Os times devem colaborar sempre que o trabalho exigir.
O inspeciona o Done Integrated com os principais stakeholders e determina adaptações futuras.
Como o objeto relevante de feedback é o produto integrado, o substitui os Reviews individuais das Teams no .
Essa é uma escolha significativa de design. Mostrar cinco demonstrações separadas de times pode criar uma ilusão de progresso enquanto ninguém experimenta a jornada combinada do usuário.
No , discute-se o progresso em direção ao , e o pode ser adaptado com base nas evidências e no feedback dos stakeholders.
O concentra-se em melhorar qualidade e eficácia em todo o .
Problemas no nível de cada time continuam importantes, mas a entrega de produto em escala também cria questões sistêmicas: falhas recorrentes de integração, dependências comuns, lacunas na , restrições de ferramentas compartilhadas, padrões de comunicação e barreiras organizacionais.
O complementa as Retrospectives das Teams ao tornar esses padrões entre times visíveis e criar ações de melhoria no nível adequado.
Ele encerra a do .
Artefatos e compromissos do em alto nível
O mantém o e o do , ao mesmo tempo em que acrescenta transparência em escala ao redor do trabalho da e da integração.
Artefato
Propósito
Compromisso
Trabalho ordenado e compartilhado em todo o produto
Visão composta do trabalho e das dependências entre times durante a
Integrated
Estado integrado atual do trabalho concluído no
e
O fornece uma visão em tempo real do trabalho que o planeja executar em direção ao e torna transparentes as dependências entre times.
Ele não elimina os Backlogs individuais das Teams. Cada time ainda precisa do próprio plano.
O descreve o propósito que o procura alcançar durante a e se alinha ao . Os Goals individuais dos times se alinham a ele.
Isso cria foco em camadas sem transformar o trabalho dos times em tarefas atribuídas centralmente.
Integrated e
O Integrated representa o trabalho integrado atual produzido pelo .
Ele deve atender à . Vários times não podem usar significados diferentes de Done para o mesmo produto e, depois, alegar que existe integração transparente.
Isso é consistente com a regra do Scrum Guide segundo a qual várias Teams trabalhando juntas em um mesmo produto devem definir mutuamente e cumprir a mesma .
O Integrated é a evidência mais forte de que o está realmente escalando a entrega do produto, em vez de apenas escalar atividade.
não elimina a necessidade de um bom design de produto e de um bom design técnico
Um framework pode tornar dependências visíveis, mas não pode eliminar magicamente acoplamento arquitetural, silos de conhecimento, limites inadequados de produto ou políticas organizacionais lentas.
O costuma revelar esses problemas mais rapidamente porque as dependências entre times se tornam difíceis de ignorar.
As organizações podem precisar mudar a composição dos times, arquitetura, automação, capacidade de /, decomposição do produto, infraestrutura ou direitos de decisão.
Nesse sentido, o é diagnóstico e também coordenativo: ele torna empiricamente visíveis os custos da escala.
Quando o pode ser apropriado
O é destinado a várias Teams trabalhando em um único produto quando a interdependência e a complexidade de integração são relevantes.
Se dois times constroem produtos genuinamente independentes, o não é a resposta natural. Se uma única equipe consegue entregar confortavelmente o produto, adicionar criaria estrutura desnecessária.
A faixa aproximada de três a nove times faz parte da definição do . Acima dessa escala, pode ser necessário considerar decomposição do produto ou múltiplas estruturas , mas essas escolhas de design dependem do contexto.
Condição
Interpretação
Várias Teams
Sim - o visa com múltiplos times
Um produto / um
Sim - premissa central
Dependências significativas
Forte caso de uso para
Necessidade de Integrated contínuo
Preocupação central do
Produtos independentes
Em geral, não - use de forma independente para cada produto
Uma
não é necessário
Exemplo prático - escalando um produto de APIs bancárias com
Imagine que um banco possua um único produto de APIs externas usado por parceiros fintech para onboarding, autenticação, pagamentos, estornos e diagnósticos operacionais. Quatro Teams trabalham no produto.
Os times usam um único e um único . O atual é permitir que parceiros regulados concluam a integração segura e a certificação em um dia útil.
Um importante introduz tokens de acesso vinculados a certificados em todo o produto. À primeira vista, a mudança parece simples, mas o Cross-Team Refinement revela dependências: a emissão de tokens afeta o onboarding; a validação no gateway afeta pagamentos e estornos; alterações de auditoria afetam observabilidade; e a documentação dos parceiros precisa mudar ao mesmo tempo.
Os times decompõem o trabalho, identificam pontos de integração e movem temporariamente um Developer experiente em identidade para um time que não possui o conhecimento necessário. O objetivo é reduzir a dependência, e não apenas agendá-la.
Durante o , o cria um : "Permitir que um parceiro-piloto conclua um pagamento de ponta a ponta usando tokens vinculados a certificado, com visibilidade completa de auditoria." Cada cria seu próprio alinhado.
O torna visíveis várias dependências entre times. Uma delas envolve um contrato de token necessário para dois times. colaboram cedo e criam testes de contrato automatizados para que a integração possa ocorrer continuamente.
O presta atenção especial ao estado integrado do produto e a saber se as dependências estão sendo removidas. Ele não atribui tarefas. Quando um ambiente de testes compartilhado se torna gargalo, o ajuda a tornar o problema sistêmico transparente e apoia a organização na criação de ambientes de teste isolados temporários.
Durante a , o revela um novo problema: um fluxo de pagamento ainda utiliza um caminho antigo de introspecção de token. Os afetados se coordenam imediatamente após o evento e adaptam seus planos.
Ao final da , todos os quatro times concluíram trabalho localmente, mas a evidência relevante é o Integrated . O parceiro-piloto consegue se cadastrar, receber o token vinculado, executar o pagamento e visualizar a trilha de auditoria. O resultado atende à .
O se concentra nessa jornada completa com os stakeholders. Um problema de usabilidade na documentação de onboarding do parceiro se torna visível somente porque o produto integrado é exercitado de ponta a ponta. O é adaptado.
No , os times identificam uma dependência arquitetural recorrente em uma biblioteca compartilhada de identidade. Eles concordam em reduzir o acoplamento nas Sprints seguintes, em vez de continuar coordenando indefinidamente em torno dele.
O exemplo ilustra o em seu melhor uso: não mais relatórios, mas mais transparência sobre as interações que determinam se múltiplos times conseguem criar um único produto utilizável.
Anti-patterns comuns do
Anti-pattern
Por que enfraquece o
como escritório de gerenciamento de projetos
O controle central substitui o autogerenciamento dos times.
executa toda a integração
A integração vira um silo separado e os times deixam de ser responsáveis pela integração do produto.
Product Backlogs separados por time
O perde uma única fonte de verdade em nível de produto.
Integração tardia
O risco se acumula até o fim da .
Dependências apenas rastreadas, nunca reduzidas
O custo de coordenação se torna permanente.
como relatório de status
A adaptação entre times vira reporte hierárquico.
Reviews separados por time
Stakeholders inspecionam saídas locais em vez do produto integrado.
Cross-Team Refinement planeja meses em detalhes
A complexidade é substituída por falsa certeza preditiva.
usado para produtos sem relação
O framework conecta times que não precisam de um Integrated .
Regras básicas do enfraquecidas "por causa da escala"
A escala vira desculpa para menos , qualidade e autogerenciamento.
Falso. é um framework complementar da .org para escalar .
exige um quando existem vários times.
Falso. Essa accountability pertence ao , não ao básico.
Cross-Team Refinement é um evento do .
Falso. É um evento do ; o refinement do continua sendo uma atividade contínua.
substitui .
Falso. se baseia no e o estende minimamente.
exige Product Owners separados para cada .
Falso. Um possui um único .
possui vários Product Backlogs.
Falso. Um trabalha a partir de um único .
O é dono de todo o trabalho de integração.
Falso. Ele é accountable pelos resultados de integração, enquanto as Teams continuam executando o trabalho.
é apenas uma demo combinada.
Falso. É um evento de inspeção e adaptação no nível do produto.
O torna dependências inofensivas ao rastreá-las.
Falso. O enfatiza minimizar e remover dependências.
é obrigatório para todo produto com múltiplos times.
Falso. É um framework opcional para escalar .
Um substitui o .
Falso. Ele alinha o esforço do na ao .
significa mais hierarquia.
Falso. Ele busca preservar a inteligência bottom-up e o autogerenciamento do .
Um framework de raciocínio para questões de na
Limite do framework: a resposta mantém separado do básico?
Um produto: várias Teams estão construindo um único produto, e não produtos sem relação?
Sistema de produto: existe um e um ?
Dependências: o está sendo usado para expor e reduzir dependências entre times?
Integração: o resultado desejado é um Done Integrated pelo menos a cada ?
: o apoia a integração sem se transformar em ?
Cross-Team Refinement: ele é reconhecido como específico do , e não como evento do ?
Eventos do : eles coordenam o trabalho em nível de produto enquanto as Teams individuais continuam utilizando ?
Artefatos: o é distinguido dos Backlogs individuais?
Qualidade: o Integrated atende à ?
Heurística rápida para o exame
Se a questão disser apenas , permaneça dentro do Scrum Guide. Se disser explicitamente , acrescente a camada do :, Cross-Team Refinement, eventos do , /Goal e Integrated .
Conclusão: o escala a transparência antes de escalar o processo
O aborda uma realidade simples, porém difícil: várias Teams podem ser eficazes individualmente e, coletivamente, incapazes de criar um único produto utilizável.
O framework foi criado por Ken Schwaber e pela .org e lançado em 2015 como uma extensão mínima do . Seu desenho atual reflete o Scrum Guide de 2020 e permanece intencionalmente leve quando comparado a muitas abordagens corporativas de escalabilidade.
Seu problema central são as dependências entre times. Dependências criam espera, custo de coordenação, risco de integração e redução do autogerenciamento. O cria estruturas que tornam essas relações mais transparentes para que os times possam reduzi-las, em vez de apenas gerenciá-las para sempre.
Integração é a segunda preocupação central. O resultado de um não é uma pilha de entregas locais de times. É um Done Integrated . Isso mantém o produto - e não o organograma - como unidade de inspeção empírica.
O acrescenta accountability pelo resultado integrado sem se transformar em um departamento central de integração. Cross-Team Refinement expõe dependências antes do . coordena um propósito em nível de . inspeciona impactos entre times. inspeciona o produto integrado. melhora o sistema entre as equipes.
O e o criam transparência no nível da escalada, enquanto o Integrated preserva um estado de produto confiável por meio da .
Mais importante para a : o continua sendo complementar. Uma não precisa de para estar aplicando corretamente. Questões sobre devem ser respondidas a partir do Scrum Guide, a menos que o faça explicitamente parte do contexto.
Na minha visão, o é valioso porque resiste ao impulso de resolver escala com camadas de gestão. Ele parte da premissa de que o verdadeiro problema está nas conexões entre os times: dependência, integração, feedback e transparência. Quando essas conexões melhoram, a organização pode escalar o aprendizado do produto, em vez de simplesmente escalar a quantidade de trabalho em andamento.
Principais conclusões
é o framework da .org para escalar entre aproximadamente três e nove Teams trabalhando em um produto.
Ken Schwaber e a .org lançaram o primeiro Guide em 2015.
O Guide foi atualizado em 2018 e 2021; a versão de 2021 foi alinhada ao Scrum Guide 2020.
se baseia no e o estende minimamente; não substitui .
é complementar e não faz parte do básico definido pelo Scrum Guide.
Um possui um e um .
O principal problema de escalabilidade que o aborda é a dependência entre times e a complexidade de integração que ela cria.
O busca produzir um Done Integrated pelo menos a cada .
O é uma accountability adicional do focada em viabilizar a integração.
O inclui o , um e Members.
Cross-Team Refinement é um evento formal do , mas não é um evento formal do .
cria um e um , enquanto as Teams mantêm seus próprios Goals e Backlogs.
se concentra em impactos e dependências entre times; as Teams continuam realizando seus próprios Daily Scrums.
inspeciona o Done Integrated e substitui os Reviews individuais dos times no .
trata de qualidade e eficácia em todo o .
O torna transparentes o trabalho da do e as dependências entre times.
O Integrated deve atender à .
O deve reduzir dependências e problemas de integração, e não apenas rastreá-los.
Não use conceitos específicos do para responder questões comuns da sobre , a menos que o contexto diga explicitamente .
