O momento mais perigoso no crescimento de uma engenharia de software é o salto de um time único para múltiplos squads. O time original entregava rápido — todo mundo sabia de tudo, decisões eram feitas no corredor, não havia handoffs formais. Com dois ou três squads, nada disso funciona mais. As dependências que antes eram invisíveis agora viram bloqueios. A velocidade cai. Todos ficam esperando todos.
Esse problema tem solução — mas ela é organizacional, não técnica. Adicionar mais cerimônias não resolve. Contratar mais gente não resolve. O que resolve é desenhar os times de forma que cada squad consiga entregar valor de forma autônoma a maior parte do tempo.
O princípio da autonomia: times que não precisam esperar outros para entregar
O objetivo da organização em squads é maximizar o tempo que cada time consegue trabalhar sem depender de outro time para avançar. Quando um squad precisa de outro squad para completar qualquer coisa, você tem um gargalo organizacional. Se isso acontece toda semana, você tem um problema de design de times.
O sinal mais claro de que os squads estão mal desenhados: o planejamento do sprint de um squad frequentemente lista tarefas que dependem de entregáveis de outro squad. Se isso é a regra, e não a exceção, os times estão divididos pela tecnologia (front aqui, back ali, dados lá) em vez de pela capacidade de entrega de produto.
Team Topologies: o framework que mudou como pensamos sobre times
O livro Team Topologies (Skelton e Pais, 2019) formalizou quatro tipos de time que cobrem praticamente todas as configurações de engenharia de software modernas. Entender esses tipos é o pré-requisito para organizar squads que funcionam.
Stream-aligned teams — são os squads de produto: alinhados a um fluxo de valor de negócio (domínio, produto, jornada do usuário). Têm todos os recursos para entregar de ponta a ponta: design, front, back, dados, devops. São os times que a empresa deveria ter mais. Exemplo: squad de checkout, squad de onboarding, squad de relatórios.
Platform teams — constroem e mantêm a plataforma interna que os squads de produto usam. CI/CD, observabilidade, infraestrutura, autenticação compartilhada. Seu "produto" é a plataforma, e seus "clientes" são os outros squads. O objetivo é reduzir a carga cognitiva dos squads de produto — quanto menos o squad de checkout precisar se preocupar com deploy e monitoring, mais ele consegue focar no checkout.
Enabling teams — times temporários de especialistas que ajudam squads de produto a adquirir novas capacidades. Segurança, performance, arquitetura, acessibilidade. Não entregam features — entregam conhecimento. Após a missão, se dissolvem ou se movem para o próximo squad que precisa de ajuda.
Complicated subsystem teams — para partes do sistema que exigem conhecimento especializado muito profundo que não faz sentido distribuir por todos os squads. Motor de precificação, algoritmo de recomendação, processamento de imagens médicas. A maioria das empresas não precisa desse tipo no início.
Contratos entre squads: o que é API não é só endpoint HTTP
A principal ferramenta de integração entre squads é o contrato explícito. Quando o squad de checkout precisa de algo do squad de catálogo, esse "algo" precisa ser documentado, versionado e tratado com a mesma seriedade que uma API pública — porque para os outros squads, ela é pública.
Contratos entre squads incluem APIs HTTP (documentadas em OpenAPI, versionadas, com SLA de estabilidade), eventos de domínio (schema dos eventos publicados no broker, incluindo campos, tipos e garantias de backward compatibility), bibliotecas internas (quando um squad publica uma biblioteca que outros usam, ela precisa de changelog e política de deprecação), e dados compartilhados (quando squads leem da mesma tabela de banco, esse schema é um contrato — mudar sem coordenação quebra outros times).
A prática de consumer-driven contracts (com ferramentas como Pact) torna esses contratos verificáveis em CI/CD: o squad consumidor define o que precisa da API, o squad provedor verifica que continua entregando. Nenhum squad quebra outro sem saber.
Inner source: compartilhando código entre squads sem criar dependências
Quando múltiplos squads precisam de uma funcionalidade parecida — autenticação, logging, componentes de UI, validadores comuns — a tentação é centralizar em um squad "dono" daquele código. O resultado invariável: esse squad vira um gargalo. Toda vez que outro squad precisa de uma mudança, abre um ticket, espera na fila, e bloqueia.
Inner source resolve isso com um modelo diferente: o código é centralizado, mas qualquer squad pode contribuir. O squad "dono" do repositório atua como mantenedor, não como único desenvolvedor. Pull requests de outros squads são bem-vindos, revisados rapidamente, e mergeados quando atendem aos padrões. O squad que precisa da mudança não espera — implementa, propõe, e colabora.
Para inner source funcionar, o repositório compartilhado precisa de: documentação clara de como contribuir, critérios explícitos de aprovação, tempo dedicado do squad mantenedor para revisar PRs externos (não é trabalho voluntário — está no planejamento), e testes que dão confiança para aceitar contribuições de quem não conhece profundamente o código.
Scrum of Scrums: sincronização entre squads sem reunião de status
Com múltiplos squads, algum nível de sincronização entre eles é inevitável. O Scrum of Scrums é a prática mais comum: representantes de cada squad se reúnem brevemente (15-30 minutos, uma ou duas vezes por semana) para compartilhar dependências e impedimentos entre times.
A diferença entre um Scrum of Scrums que funciona e um que vira reunião de status inútil está nas perguntas certas. Em vez de "o que cada squad fez essa semana" (isso está no board), as perguntas úteis são: qual squad tem uma entrega que bloqueia outro squad? Existe alguma dependência entre squads que não está mapeada? Algum squad está bloqueado por outro e ainda não pediu ajuda?
O representante no Scrum of Scrums não é necessariamente o tech lead ou o PO — é quem tem melhor visibilidade das dependências do squad com outros times. Em squads maduros, o papel rotaciona.
Roadmap compartilhado: como evitar surpresas entre squads
A maioria dos conflitos entre squads começa semanas antes de virarem um problema visível: o squad A planeja uma feature que vai precisar de uma API do squad B, mas nunca comunicou. O squad B planeja uma refatoração que vai mudar a API que o squad A usa, mas o squad A só descobre quando o build quebra.
A solução é uma visibilidade de roadmap compartilhada — não um Gantt detalhado, mas um mapa de intenções com horizonte de 4 a 8 semanas. Cada squad publica o que planeja entregar nas próximas semanas e o que vai precisar de outros squads para isso. O PI Planning do SAFe é uma versão formal disso (com cerimônias de 2 dias), mas para a maioria das empresas uma versão mais leve funciona melhor: uma hora por mês onde cada squad apresenta seu roadmap e explicita dependências.
Quando squads precisam entregar juntos: o release train
Às vezes a natureza do produto exige que múltiplos squads entreguem em sincronia — uma nova feature de produto que envolve mudanças no checkout, no catálogo e nas notificações ao mesmo tempo. Para esses casos, o conceito de release train ajuda: um ciclo de release com data definida em que múltiplos squads coordenam suas entregas.
O release train não elimina a autonomia dos squads — ele apenas cria um ponto de coordenação explícito para as situações que genuinamente requerem isso. A maioria das entregas ainda deve acontecer de forma independente. Quando o release train vira o padrão para toda entrega, você voltou ao modelo de projeto com fases e handoffs.
Métricas de saúde da integração entre squads
Como saber se a organização em squads está funcionando? Algumas métricas que revelam o estado real da integração entre times: porcentagem de histórias bloqueadas por dependência externa (se for alta toda sprint, os squads estão mal desenhados); tempo médio de resolução de uma dependência entre squads (quanto tempo um squad espera outro para avançar?); número de quebras de contrato (quantas vezes um squad mudou algo que quebrou outro sem avisar?); e satisfação do desenvolvedor (times bem integrados têm desenvolvedores que conseguem trabalhar com foco — times mal integrados têm desenvolvedores constantemente interrompidos por dependências e alinhamentos).
O sinal de que a organização precisa mudar
Squads não são permanentes. À medida que o produto e a empresa evoluem, a organização de times também precisa evoluir. O sinal mais claro de que é hora de redesenhar os squads: dois squads passam mais tempo coordenando entre si do que entregando. Nesse caso, eles provavelmente deveriam ser um único squad — ou as responsabilidades precisam ser redesenhadas para que a fronteira entre eles seja mais clara.
A lei de Conway diz que a arquitetura do software tende a refletir a estrutura de comunicação da organização. Isso funciona nos dois sentidos: se você tem dois squads que precisam estar muito alinhados, seus sistemas provavelmente estão acoplados demais. E se você quer sistemas mais desacoplados, reorganizar os times pode ser mais eficaz do que refatorar o código.
Escalar uma engenharia de software vai muito além de contratar mais desenvolvedores. Se você quer estruturar sua organização de times para crescer com velocidade e qualidade, a Neryx pode ajudar com um diagnóstico e plano de ação.