Como vários Scrum Teams coesos trabalham em um único produto por meio de um Product Goal compartilhado, um Product Backlog, um Product Owner, uma Definition of Done, integração contínua, dependências transparentes e comunicação que preserva o empirismo em escala
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 Scrum Guide exige quando vários Teams trabalham no mesmo produto, como a identidade do produto conduz a um , e compartilhados, por que os times devem definir mutuamente e cumprir a mesma , como a e a redução de dependências sustentam um , como a comunicação muda em escala e por que frameworks de escala, como , são extensões opcionais, e não exigências do .
Introdução: escalar começa protegendo o produto, não multiplicando processos
No momento em que vários Teams trabalham no mesmo produto, o problema mais difícil deixa de ser como criar mais times. Passa a ser como impedir que um único produto se fragmente em vários sistemas concorrentes.
O foi deliberadamente concebido em torno de times pequenos, coesos e . Times pequenos se comunicam rapidamente, adaptam-se localmente e conseguem manter um entendimento compartilhado de objetivos e qualidade. O crescimento cria uma tensão: um produto pode se tornar grande demais para um único , mas adicionar pessoas também aumenta os caminhos de comunicação, o trabalho de integração, as dependências e o custo de coordenação.
O Scrum Guide trata disso diretamente. Se um se tornar grande demais, deve considerar a reorganização em vários Teams coesos focados no mesmo produto. Esses times devem compartilhar o mesmo , e .
Essa frase é uma das regras de escala mais importantes no corpo de conhecimento da . A unidade que está sendo escalada não é o backlog, a hierarquia nem o departamento. É o produto. Se vários times atendem a um único produto, esse produto ainda precisa de uma direção coerente e de uma fonte transparente de trabalho.
A qualidade também precisa permanecer coerente. O Scrum Guide atual afirma que, quando vários Teams trabalham juntos em um produto, eles devem definir mutuamente e cumprir a mesma . Sem esse limite de qualidade compartilhado, o “Done” de um time pode ser incompatível com o de outro, tornando opaco o estado geral do produto.
A escala também expõe o custo das dependências. O Time A não consegue terminar até que o Time B altere uma API. O Time C espera por um especialista compartilhado em banco de dados. A integração acontece no fim da e revela premissas incompatíveis. Cada time local parece produtivo, enquanto o do produto continua inutilizável.
Por isso, a escala madura concentra grande atenção na redução de dependências entre times e na do trabalho. O framework , da .org, torna isso explícito, mas o problema subjacente existe independentemente da adoção do .
O objetivo deste capítulo não é prescrever um único framework de escala. É explicar as regras centrais do e o necessários quando vários Teams criam um único produto. Examinaremos identidade do produto, artefatos compartilhados, accountability do ,, integração, dependências, comunicação, feedback e armadilhas organizacionais que surgem quando a escala é tratada por meio de hierarquia, e não de .
Uma breve história da escala no
O surgiu no início da década de 1990 com pequenos times de desenvolvimento de produtos. À medida que organizações passaram a adotar em produtos maiores, a coordenação entre vários times tornou-se um desafio prático.
As primeiras organizações experimentaram e outros padrões de coordenação. Posteriormente, surgiram abordagens mais formais de escala. Ken Schwaber e a .org lançaram o em 2015 e atualizaram seu guia em versões posteriores, inclusive em janeiro de 2021. O estende minimamente o para ajudar aproximadamente de três a nove Teams a trabalhar a partir de um e produzir um Integrated .
Outros frameworks de escala também existem, mas nenhum deles é exigido pelo Scrum Guide. O permanece intencionalmente incompleto e permite práticas complementares que respeitem suas regras.
Para a , portanto, o conhecimento mais importante é o design central do . Uma questão sobre vários Teams não exige automaticamente uma resposta baseada em algum framework de escala.
Limite para a
O não exige ,,, nem qualquer outro framework de escala. Essas abordagens podem ser complementares; o Scrum Guide continua definindo as regras essenciais.
Um produto: a primeira decisão de escala
Antes de discutir times, determine se o trabalho realmente pertence a um único produto.
O Scrum Guide descreve produto como um veículo para entregar valor, com limite claro, stakeholders conhecidos e usuários ou clientes bem definidos. Um produto pode ser um serviço, um produto físico, um produto de software ou algo mais abstrato.
Se vários times atendem ao mesmo limite coerente de produto e à mesma proposta de valor ao cliente, separá-los em estruturas de produto independentes pode criar prioridades concorrentes, otimização duplicada e atrito de integração.
Por outro lado, chamar artificialmente serviços não relacionados de um único produto pode produzir um tão amplo que uma ordenação significativa se torna difícil. Os limites do produto devem sustentar decisões de valor e feedback empírico.
Figura 1. Vários Teams no mesmo produto compartilham um , um e um .
Um
O é o objetivo de longo prazo do e o compromisso do . Quando vários Teams trabalham em um único produto, eles precisam do mesmo porque estão coletivamente melhorando o mesmo produto.
Um compartilhado cria um alvo comum de otimização. O Time A não deve maximizar um objetivo local de subsistema se isso prejudicar o resultado global do produto. O Time B não deve otimizar a entrega de seu componente às custas da jornada do usuário.
Teams diferentes podem ter Goals diferentes porque o plano de de cada time pode contribuir de maneira distinta para o compartilhado. O alinha a direção do produto; os Goals concentram os Teams individuais na atual.
Distinção importante
Um produto -> um ativo. Vários Teams ainda podem ter Goals diferentes que contribuam para essa direção de produto.
Um
O é a lista emergente e ordenada do que é necessário para melhorar o produto e a única fonte de trabalho realizado pelo .
Quando vários Teams trabalham no mesmo produto, dividir o trabalho em backlogs separados por time cria várias fontes da verdade. A ordenação torna-se local, dependências entre times ficam mais difíceis de enxergar e stakeholders podem contornar decisões de produto pressionando times individualmente.
Um compartilhado não significa que todo Developer precise discutir cada item. Significa que o trabalho do produto é transparente em um único sistema ordenado e pode ser refinado até um nível em que os times compreendam dependências, valor e provável responsabilidade de execução.
Atributos, tags, componentes ou views podem ajudar os times a navegar pelo sem fragmentar a accountability do produto.
Abordagem
Efeito provável
único
Ordenação no nível do produto, transparência de dependências e uma única fonte de trabalho.
Backlogs separados por time para o mesmo produto
Prioridades concorrentes, dependências ocultas e otimização local.
Backlog compartilhado com views de time/componente
Navegação útil, preservando a verdade no nível do produto.
Um
O continua sendo uma pessoa, não um comitê. Isso é especialmente importante em escala, porque o número de stakeholders e interesses concorrentes normalmente aumenta.
O é accountable por maximizar o valor do produto, desenvolver e comunicar o , criar e comunicar claramente os Items, ordenar o e garantir que ele seja transparente e compreendido.
O trabalho pode ser delegado, e representantes ou especialistas de domínio podem ajudar no gerenciamento do backlog, mas a accountability não se divide em vários Product Owners para o mesmo .
Um anti-padrão comum de escala cria um “” por time enquanto uma pessoa em nível superior gerencia a direção do produto. A menos que essas pessoas em nível de time sejam de fato Product Owners de produtos diferentes, o modelo fragmenta a accountability.
Armadilha da
Um produto não se transforma em três produtos apenas porque três Teams trabalham nele. Para o mesmo produto, o espera um , um e um .
Mesma : um significado transparente de qualidade
A é a descrição formal do estado do quando ele atende às medidas de qualidade exigidas para o produto.
O Scrum Guide atual é explícito: se vários Teams trabalham juntos em um produto, eles devem definir mutuamente e cumprir a mesma .
Essa exigência protege a transparência. Imagine que o Time A considere código Done após testes unitários, enquanto o Time B exija deployment pronto para produção, security scanning, testes integrados e observabilidade. O produto não pode ter um estado confiável porque “Done” significa coisas diferentes.
Uma compartilhada não exige técnicas internas de engenharia idênticas. Os times podem usar ferramentas ou práticas de implementação diferentes, mas o resultante deve atender ao mesmo estado de qualidade em nível de produto.
Situação
Interpretação
Mesma
Todos podem inspecionar o produto usando um único limite de qualidade.
DoDs diferentes para o mesmo produto
O estado integrado do produto se torna ambíguo e o risco se acumula.
Existe um padrão organizacional
Todos os times o seguem como mínimo.
Os times precisam de qualidade mais forte
Podem fortalecer as práticas, desde que a compartilhada do produto seja satisfeita.
Integração: o produto deve tornar-se um
O exige que cada seja aditivo aos Incrementos anteriores e completamente verificado para que todos os Incrementos funcionem juntos. Em escala, isso se torna muito mais difícil.
Um anti-padrão perigoso permite que cada time crie um componente localmente Done e adie a integração do produto para o final da , do ciclo de release ou para uma especial de integração. A integração passa então a ser uma fase, e não uma atividade contínua de qualidade.
O cliente, porém, não recebe o backend do Time A, a interface do usuário do Time B e o pipeline de dados do Time C como três produtos independentes. Ele experimenta o sistema integrado.
A reduz incerteza ao combinar o trabalho com frequência suficiente para que incompatibilidades sejam descobertas enquanto ainda são pequenas. Build automatizado, testes, deployment, verificação de contratos, ambientes compartilhados, observabilidade e interfaces claras podem sustentar a integração.
O não prescreve ferramentas de /, mas um de produto utilizável não pode ser declarado se o trabalho combinado não funcionar de fato em conjunto.
Figura 2. A qualidade em escala depende da visibilidade contínua das dependências e da do trabalho de produto.
Regra de integração
Conclusão local não é suficiente. A evidência relevante é se o do produto está integrado, utilizável e atende à compartilhada.
Dependências: o custo central da escala
As dependências se multiplicam à medida que os times dividem o trabalho. Um time precisa da API, decisão, ambiente, modelo de dados, biblioteca, especialista ou deployment de outro time antes de conseguir terminar.
Dependências reduzem a porque um time não consegue concluir valor de forma independente. Elas também criam filas, reuniões de sincronização, espera, handoffs e incerteza de .
O é construído em torno dessa percepção: sua finalidade principal é minimizar dependências entre times e problemas de integração, preservando o .
A solução mais forte costuma ser estrutural, e não administrativa. Em vez de melhorar uma planilha de rastreamento de dependências, reduza a dependência por meio de , arquitetura, decomposição do produto, automação, propriedade compartilhada ou limites de time diferentes.
Dependência
Exemplo
Direção de melhoria
Propriedade de componente
Time A não pode alterar a UI até que o Time B altere o serviço.
Slices verticais de produto, propriedade compartilhada, contratos estáveis.
Dependência de especialista
Todos os times esperam por um único especialista em banco de dados/segurança.
Cross-skill, incorporar a capacidade, automatizar padrões.
Dependência de ambiente
Um único ambiente compartilhado cria fila.
Ambientes self-service, automação, virtualização.
Dependência de decisão
Comitê de arquitetura aprova todas as mudanças.
Guardrails delegados, limites mais claros, feedback mais rápido.
Dependência de release
Times integram apenas na janela de release.
e capacidade de deployment no nível do produto.
Refinement entre times: torne as dependências visíveis antes da
O Scrum Guide define como o desdobramento e esclarecimento contínuos dos Items. Com vários times, o refinement também se torna uma oportunidade importante para expor dependências entre times.
O próprio não define um evento obrigatório de refinement entre times. Os times podem coordenar o refinement da forma que sustente a transparência.
O adiciona uma prática específica de Cross-Team Refinement porque as dependências são muito relevantes em escala. Ela ajuda os times a identificar qual time pode entregar qual PBI e a detectar dependências cedo o bastante para removê-las ou minimizá-las.
O princípio se aplica mesmo sem : se os times descobrem grandes dependências apenas durante a ou a implementação, provavelmente o não estava transparente o suficiente para a escala envolvida.
Comunicação: mais times criam mais caminhos
Quando um tem sete pessoas, a comunicação direta é relativamente administrável. Adicionar vários times não aumenta a comunicação de forma linear; as interações possíveis se multiplicam.
As organizações frequentemente respondem adicionando camadas de coordenadores e reuniões de status. Isso pode reduzir a comunicação direta e criar perda de informação.
Um padrão mais saudável usa artefatos transparentes, linguagem compartilhada de produto, APIs ou interfaces claras, evidências comuns de integração, colaboração direta entre as pessoas que precisam umas das outras e eventos direcionados entre times quando existe uma necessidade real de coordenação.
Nem todos os membros de todos os times precisam participar de toda conversa entre times. A comunicação deve conectar as pessoas necessárias para a decisão ou dependência, preservando o foco dos times.
Mecanismo de comunicação
Finalidade
compartilhado
Reduz versões conflitantes das prioridades do produto.
comum
Cria linguagem compartilhada para qualidade e integração.
Colaboração direta entre
Reduz handoffs por meio de coordenadores.
Dashboards/evidências de integração compartilhados
Tornam transparente o estado combinado do produto.
Refinement direcionado entre times
Expõe dependências antes que elas se tornem blockers da .
Inspeção conjunta com stakeholders quando útil
Cria um único de produto, em vez de demos isoladas por time.
com vários times
Cada possui sua própria porque cada cria seu próprio e .
Entretanto, quando os times compartilham um produto, seus planos podem interagir. Dependências, trabalho de integração, progresso em direção ao e ambientes compartilhados podem exigir coordenação.
O não exige uma única gigantesca para todos os times. A exigência essencial é que cada consiga fazer uma realista enquanto o trabalho global do produto permanece transparente e integrável.
O fornece o como mecanismo opcional em escala para coordenar times. Sem , organizações ainda podem usar padrões leves de coordenação que preservem a de cada time.
Coordenação diária sem transformar em uma hierarquia de status
Cada possui sua para seus . Uma dependência entre times não transforma a em uma reunião corporativa de status.
Os times podem precisar de coordenação direta adicional quando surgem riscos de integração ou dependências. As pessoas envolvidas podem colaborar imediatamente em vez de esperar por uma cerimônia agendada.
Algumas abordagens de escala adicionam coordenação diária entre times. O , por exemplo, define uma focada em problemas de integração. Isso é opcional fora do .
O princípio é coordenar o trabalho do produto, não construir uma hierarquia na qual representantes dos times reportem para cima.
: inspecione um produto, não uma coleção de outputs de times
A existe para inspecionar o resultado da e determinar adaptações futuras. Quando vários times trabalham em um produto, o feedback dos stakeholders deve, em última instância, tratar do produto integrado e do progresso em direção ao compartilhado.
Demonstrações separadas por time podem ser úteis localmente, mas, se os stakeholders veem componentes independentemente e ninguém inspeciona o produto combinado, os riscos de integração e valor permanecem ocultos.
Uma Review forte no nível do produto mostra o atual, discute o que mudou no ambiente, examina o progresso em direção ao e adapta o .
O utiliza uma única que substitui as Reviews individuais dos Teams porque o produto integrado é o objeto relevante de inspeção. O , isoladamente, não prescreve exatamente como as Reviews de múltiplos times devem ser organizadas, mas o princípio empírico permanece: inspecione o resultado do produto, e não apenas outputs locais.
Retrospectives e melhoria sistêmica
Cada precisa inspecionar e melhorar sua própria efetividade. Em escala, alguns problemas pertencem ao sistema entre os times, e não a um individual.
Exemplos incluem falhas recorrentes de integração, lacunas comuns na , gargalo em um ambiente compartilhado, acoplamento arquitetural ou uma fila centralizada de revisão.
Os times precisam de um mecanismo para inspecionar esses problemas sistêmicos em conjunto e adaptar o sistema mais amplo de entrega. O adiciona uma para esse fim; outras organizações podem usar outra abordagem complementar.
Não force um único time a “corrigir” uma dependência criada por uma estrutura organizacional que ele não controla. Melhorias de escala frequentemente exigem liderança organizacional.
Desafios de escala: mais pessoas podem reduzir a capacidade de entrega
A escala é frequentemente tratada como um problema de capacidade: se um time entrega X, três times deveriam entregar 3X. Sistemas de produto complexos raramente se comportam dessa forma.
Mais times criam mais caminhos de comunicação, superfícies de integração, necessidades de coordenação, premissas inconsistentes e dependências. Pessoas novas exigem onboarding. A arquitetura pode não sustentar trabalho independente.
O Guide observa explicitamente que escalar valor nem sempre exige adicionar mais pessoas e que, às vezes, reduzir o número de pessoas trabalhando em algo pode melhorar a entrega de valor.
A pergunta correta não é “Quantos times podemos adicionar?”, mas “O que está impedindo o sistema atual de entregar mais valor, e outro time reduzirá ou aumentará essa restrição?”.
Desafio de escala
Consequência típica
Otimização local
Times maximizam a entrega de componentes em vez do resultado do produto.
Propriedade fragmentada
Vários pseudo-Product Owners criam prioridades conflitantes.
Integração tardia
Trabalho localmente Done falha quando combinado.
Explosão de dependências
Times passam mais tempo esperando e coordenando.
Sobrecarga de comunicação
Reuniões se multiplicam e a informação direta passa a ser filtrada.
Padrões de qualidade diferentes
O estado do produto deixa de ser transparente.
Arquitetura seguindo limites dos times
Silos organizacionais endurecem e viram acoplamento do produto.
Escala antes da clareza do produto
Mais capacidade acelera trabalho incerto ou de baixo valor.
Framework opcional de escala:
é o framework da .org para escalar . Ele se baseia no e o estende minimamente para aproximadamente três a nove Teams trabalhando juntos em um único produto.
Um possui um e um . Sua finalidade é minimizar dependências e problemas de integração e produzir um Integrated pelo menos uma vez a cada .
O adiciona accountabilities, eventos e artefatos, como , Cross-Team Refinement, ,,,,, e Integrated .
Esses elementos não fazem parte do básico. Eles só se tornam exigidos se uma organização optar por utilizar o conforme definido.
Segurança para a prova
Se uma questão da perguntar o que o exige, responda primeiro com base no Scrum Guide. Não importe papéis, eventos ou artefatos específicos do , a menos que a questão diga explicitamente “”.
Exemplo prático - três Teams construindo um único produto de APIs bancárias
Imagine que um banco digital possua um único produto de APIs usado por parceiros fintech externos. O crescimento torna o original grande demais, então a organização se reorganiza em três Teams coesos.
O Time A possui forte experiência em onboarding de parceiros e segurança. O Time B possui habilidades em domínio de pagamentos e processamento de transações. O Time C possui capacidades de observabilidade, portal de e automação de plataforma. A organização toma cuidado para não defini-los como silos permanentes de componentes; cada time permanece suficientemente para criar mudanças verticais úteis no produto.
Os três times compartilham um : “Permitir que parceiros fintech regulamentados integrem e concluam jornadas de pagamento certificadas em até um dia útil.” Há um e um .
Durante o refinement, um PBI de alto valor introduz access tokens vinculados a certificados. Os times descobrem que o trabalho afeta onboarding de parceiros, emissão de tokens, validação no gateway, observabilidade, documentação e ferramentas de teste.
Se cada time trabalhar de forma independente, as dependências aparecerão tarde. Em vez disso, dos times relevantes refinam a mudança de produto em conjunto. Eles dividem o trabalho em slices orientados a produto, identificam alterações de interface compartilhadas e combinam como as evidências de integração serão produzidas continuamente.
Os times utilizam a mesma . Entre outras medidas de qualidade, ela exige testes automatizados integrados, validação de segurança, eventos de auditoria, observabilidade, backward compatibility para versões de parceiros suportadas e capacidade de deployment.
O Time A cria a primeira capacidade de enrollment de parceiro. O Time B adiciona validação de token aos fluxos de pagamento. O Time C atualiza ferramentas self-service para parceiros e observabilidade. O pipeline de integra alterações ao longo da em vez de esperar por um merge final.
Uma dependência surge: o Time B precisa de uma alteração no serviço de identidade que está sendo construída pelo Time A. Em vez de criar um handoff por meio de um gerente de projeto, os colaboram diretamente e definem um teste de contrato temporário. Os times adaptam a sequência para que a interface fique disponível cedo.
Na , os stakeholders inspecionam a jornada integrada do produto, e não três apresentações separadas de times. Um parceiro consegue fazer enrollment, receber um token vinculado a certificado, chamar a API de pagamento e visualizar diagnósticos pelo portal. O fluxo integrado expõe um problema de usabilidade que nenhum dos componentes em nível de time revelou isoladamente.
O adapta o com base nesse feedback. Os Goals dos times para a seguinte são diferentes, mas todos continuam contribuindo para o mesmo .
Durante as Retrospectives, cada melhora seu próprio trabalho. Uma discussão mais ampla entre times também revela que um ambiente compartilhado de staging está se tornando um gargalo. A organização investe em ambientes self-service para remover a dependência sistêmica.
O resultado importante não é “três times fazendo ”. É um produto avançando empiricamente por meio de um ordenado em direção a um , com e progressivamente menos dependências.
Anti-padrões comuns de com múltiplos times
Anti-padrão
Por que enfraquece o em escala
Um backlog por time para um produto
A ordenação do produto se fragmenta e as dependências ficam ocultas.
Um por time para o mesmo produto
A accountability de valor se torna ambígua ou hierárquica.
Product Goals diferentes por componente
Os times otimizam subsistemas em vez de um resultado único de produto.
Definitions of Done diferentes
A do produto se torna opaca.
de integração
O risco de integração é adiado, em vez de ser inspecionado continuamente.
Times permanentes por componente com muitos handoffs
As dependências endurecem na organização.
Reunião entre times para cada detalhe
A sobrecarga de coordenação destrói o foco.
Gerente de projeto distribui trabalho entre os times
A é substituída por controle centralizado.
Apenas demos separadas para stakeholders
Ninguém inspeciona o resultado real do produto integrado.
Adicionar times para resolver todo problema de entrega
Mais pessoas amplificam a complexidade de comunicação e dependências.
Armadilhas comuns da sobre múltiplos Teams
Armadilha
Interpretação correta do
Vários times em um produto devem ter Product Backlogs separados.
Falso. Eles devem compartilhar o mesmo .
Cada precisa de seu próprio para o mesmo produto.
Falso. Eles compartilham o mesmo .
Cada time deve perseguir seu próprio .
Falso para o mesmo produto. Eles compartilham um .
Vários times podem usar Definitions of Done diferentes.
Falso. Eles devem definir mutuamente e cumprir a mesma .
Todos os times precisam ter o mesmo .
Falso. Goals pertencem ao de cada .
O exige quando há vários times.
Falso. é um framework opcional de escala.
O exige .
Falso. É um padrão complementar de coordenação, não um elemento do .
A integração pode acontecer depois que todos os times terminarem seu trabalho.
Raciocínio fraco em . O do produto deve estar integrado e utilizável.
O atribui PBIs aos times.
Não é uma exigência do . e colaboram; os times permanecem .
Mais times significam automaticamente mais produtividade.
Falso. Times adicionais também aumentam dependências e complexidade de comunicação.
Concluir um componente é suficiente para Done.
Falso se o produto combinado não atender à compartilhada.
Escalar significa adicionar hierarquia para coordenar os times.
Não é exigido. O busca transparência, , colaboração direta e .
Um framework de raciocínio para questões da sobre múltiplos times
Um produto: os times realmente trabalham dentro do mesmo limite de produto?
: eles compartilham um para esse produto?
: existe uma única fonte ordenada do trabalho do produto?
: uma pessoa é accountable pelo valor do produto e pelo gerenciamento do ?
: todos os times definem mutuamente e cumprem o mesmo estado de qualidade em nível de produto?
Integração: o trabalho combinado se torna um , em vez de outputs locais separados?
Dependências: são expostas cedo e ativamente reduzidas, em vez de apenas agendadas?
Comunicação: a informação flui diretamente o suficiente para preservar transparência sem hierarquia desnecessária?
: os Teams mantêm autoridade sobre como organizam e executam seu trabalho?
Framework de escala: a resposta evita tratar ou outro framework como obrigatório, a menos que isso seja explicitamente declarado?
Heurística rápida para a prova
Vários Teams + mesmo produto = mesmo , mesmo , mesmo e mesma . Todo o restante deve proteger integração, transparência, e valor.
Conclusão: escalar significa preservar um produto enquanto se reduz o custo de muitos times
Vários Teams podem ampliar a capacidade disponível para um produto complexo, mas a escala também introduz uma nova fonte de complexidade: os próprios times agora precisam integrar conhecimento, decisões, código, qualidade e feedback.
O Scrum Guide protege a coerência do produto por meio de um pequeno conjunto de regras poderosas. Times que trabalham no mesmo produto compartilham o mesmo , e . Esses elementos criam uma direção, uma fonte ordenada de trabalho e um ponto único de accountability de valor.
A qualidade recebe proteção igualmente forte. Vários Teams em um produto devem definir mutuamente e cumprir a mesma . Sem um único limite de qualidade, ninguém consegue inspecionar o verdadeiro estado do produto.
A integração, portanto, não é um detalhe administrativo posterior. Um de produto deve ser aditivo, verificado, utilizável e funcionar com os Incrementos anteriores. e descoberta antecipada de dependências reduzem o risco de que times localmente bem-sucedidos produzam coletivamente um sistema inutilizável.
Dependências são o principal imposto da escala. Algumas podem ser gerenciadas temporariamente, mas organizações maduras as reduzem alterando habilidades dos times, arquitetura, estrutura do produto, automação, ambientes, direitos de decisão e padrões de comunicação.
A comunicação deve se expandir apenas onde o produto precisar. Mais reuniões não criam automaticamente mais transparência. Artefatos compartilhados, colaboração direta, feedback no nível do produto e evidências visíveis de integração podem reduzir a necessidade de hierarquia de coordenação.
Frameworks como podem ajudar quando a escala se torna significativa. O torna dependências e integração explícitas por meio de eventos, accountabilities e artefatos adicionais. Mas a base da continua sendo o próprio , e o não é exigido a menos que seja explicitamente escolhido.
Na minha visão, o sinal mais forte de uma escala saudável é que adicionar times não fragmenta o . Os stakeholders continuam vendo um único produto. O continua fazendo uma ordenação coerente de valor. Os continuam responsáveis por como trabalham. A qualidade continua tendo um único significado transparente. E cada continua produzindo evidências sobre o produto integrado, em vez de uma coleção de componentes esperando que alguém os monte.
Principais pontos
Se um se tornar grande demais, ele pode se reorganizar em vários Teams coesos focados no mesmo produto.
Vários Teams trabalhando no mesmo produto compartilham o mesmo .
Eles compartilham um como fonte ordenada do trabalho do produto.
Eles compartilham um ; o continua sendo uma pessoa, e não um comitê.
Os times devem definir mutuamente e cumprir a mesma .
Teams diferentes podem ter Goals diferentes enquanto contribuem para o mesmo .
Views ou tags no podem ajudar os times a navegar pelo trabalho sem criar backlogs separados para o produto.
O estado integrado do produto importa mais do que a conclusão local de componentes.
A reduz riscos e revela premissas incompatíveis mais cedo.
Dependências são uma grande fonte de complexidade de escala e devem ser ativamente minimizadas.
Refinement entre times pode expor dependências antes da ; o não exige um evento formal específico para isso.
A complexidade de comunicação cresce com o número de times, por isso colaboração direta e orientada a propósito é importante.
As Reviews devem preservar inspeção no nível do produto e feedback dos stakeholders.
Problemas sistêmicos entre times exigem adaptação organizacional, e não apenas ações locais de Retrospective.
Adicionar mais times pode aumentar a complexidade e não garante maior entrega de valor.
é um framework opcional da .org que estende minimamente o para vários times.
O não exige ,,, nem qualquer framework específico de escala.
