Escalar Agile Sem SAFe: Abordagens Leves para Organizações de Engenharia em Crescimento
Aqui está um padrão que já vi acontecer pelo menos uma dúzia de vezes. Uma startup cresce de uma equipa para três ou quatro. A coordenação fica confusa. Alguém propõe o SAFe (Scaled Agile Framework) como solução. Seis meses depois, a organização de engenharia está a afogar-se em cerimónias de PI Planning, Agile Release Trains, e definições de papéis que ninguém consegue manter. Os engenheiros passam mais tempo em reuniões de alinhamento do que a escrever código.
O SAFe resolve um problema real. Mas para a maioria das organizações de engenharia entre 20 e 50 engenheiros, é a solução errada — uma framework concebida para empresas com centenas de engenheiros, comprimida numa organização de escala média.
O Problema Real que o SAFe Tenta Resolver
Sejamos justos para com o SAFe ao nomear o que aborda. Quando passas de uma equipa para múltiplas equipas, encontras problemas de coordenação que não existiam antes:
- Dependências entre equipas. A Equipa A não consegue lançar a sua funcionalidade até a Equipa B terminar a API de que precisa. Ninguém descobre até ao último dia do sprint.
- Prioridades conflituosas. A equipa de produto diz à Squad 1 que a funcionalidade X é urgente, enquanto a Squad 2 está a trabalhar em infraestrutura de que a funcionalidade X depende — mas ninguém ligou os pontos.
- Bases de código e serviços partilhados. Múltiplas equipas a fazer deploy para os mesmos serviços, às vezes a sobrescrever as mudanças umas das outras ou a causar regressões inesperadas.
- Alinhamento estratégico. Cada equipa otimiza para o seu próprio backlog sem compreender como o seu trabalho se liga aos objetivos trimestrais da empresa.
Estes são problemas reais. Já os vivi todos. A questão não é se precisas de os abordar. É quanto overhead de processo é justificado para o teu tamanho de organização.
Por Que o SAFe Ultrapassa no Médio Escala
O SAFe introduz uma estrutura massiva: Incrementos de Programa, Agile Release Trains, Release Train Engineers, System Demos, Solution Trains, e toda uma taxonomia de papéis e cerimónias. Para uma organização de 200 engenheiros na área da saúde ou finanças, talvez justificado. Para uma startup de 30 engenheiros com quatro squads? Eis por que é absurdo:
O overhead de cerimónias é brutal. O PI Planning por si só é um evento de dois dias a cada 8-12 semanas. Adiciona preparação, acompanhamento e cerimónias contínuas, e adicionaste dias de reuniões por trimestre ao calendário de cada engenheiro.
A proliferação de papéis adiciona custo sem valor. Release Train Engineer, Solution Architect, Epic Owners — numa organização de 30 pessoas, esses papéis ou não existem ou são preenchidos por pessoas já sobrecarregadas.
Otimiza para previsibilidade em detrimento de velocidade. Bloquear em compromissos de PI de 10 semanas prejudica ativamente a tua capacidade de responder ao feedback do mercado.
Desencoraja a comunicação informal. "Isso é um tópico do Scrum de Scrums" torna-se uma desculpa para não enviar uma mensagem à pessoa que pode desbloquear-te agora mesmo.
A Alternativa Leve: O Que Realmente Funciona
Já vi as seguintes abordagens funcionar bem para organizações na faixa de 20-50 engenheiros. Resolvem os mesmos problemas de coordenação com uma fração do overhead.
Sincronização Semanal Entre Equipas (30 minutos)
Um representante de cada equipa junta-se a uma reunião semanal. A agenda é simples:
- O que estás a lançar esta semana? (2 minutos por equipa)
- O que te está a bloquear de outra equipa? (surfaça dependências)
- O que está a mudar que outros devem saber? (serviços partilhados, mudanças de API, atualizações de infraestrutura)
É isso. Sem relatórios de estado. Sem percentagens de progresso. Se algo necessita de discussão mais profunda, agenda um acompanhamento. A sincronização é para surfaçar, não para resolver.
Workshop Trimestral de Mapeamento de Dependências (meio dia)
Uma vez por trimestre, os team leads e product managers mapeiam o trabalho planeado do próximo trimestre num quadro partilhado. Não um plano detalhado — um mapa aproximado de dependências. Estás à procura de: duas equipas a alterar o mesmo serviço, funcionalidades que dependem de trabalho não priorizado, infraestrutura partilhada que ninguém detém.
Este é o núcleo útil do PI Planning, despojado de cerimónia. Meio dia em vez de dois dias. Escreve dependências num quadro Miro, atribui proprietários, segue em frente.
Sprint Reviews Conjuntas
Em vez de cada equipa fazer a sua sprint review isoladamente, faz uma sessão de demo partilhada a cada duas semanas (ou mensalmente, dependendo da tua cadência). Cada equipa mostra o que lançou. O público são as outras equipas.
Isto faz três coisas:
- Constrói compreensão partilhada. Os engenheiros veem o que outras equipas estão a trabalhar e como o produto se liga.
- Cria coordenação informal. "Ah, estás a construir isso? Temos uma necessidade semelhante — falamos depois."
- Eleva a qualidade. Quando sabes que outros engenheiros vão ver o teu trabalho, és mais intencional sobre o que lança.
Mantém-no apertado. 10 minutos por equipa, no máximo. Se as demos se prolongam, deixam de ser úteis.
Backlogs Partilhados para Trabalho de Plataforma
Se múltiplas equipas dependem de infraestrutura partilhada, cria um backlog de plataforma para o qual qualquer equipa pode contribuir. Ainda não precisas de uma equipa de plataforma dedicada. Mas precisas de uma lista visível e priorizada de trabalho de plataforma para que não se perca no backlog de funcionalidades de cada equipa. Atribui um proprietário — normalmente um engenheiro sénior ou tech lead — para priorizar e garantir que o trabalho é recolhido.
Rituais entre Squads
Duas práticas leves que pagam dividendos desproporcionais:
Tech talks. A cada duas semanas, um engenheiro apresenta algo durante 20-30 minutos. Uma nova ferramenta, uma decisão arquitetural, um incidente em produção. Espalha conhecimento e constrói relações entre equipas.
Parceiros de revisão rotativos. Atribui revisores entre equipas para PRs que tocam serviços partilhados. Isto deteta problemas de integração cedo e constrói familiaridade entre equipas.
Quando o SAFe Realmente Faz Sentido
Não sou contra o SAFe categoricamente. Há contextos onde o overhead é justificado:
- Organizações muito grandes (100+ engenheiros) onde a coordenação informal fisicamente não consegue escalar
- Indústrias reguladas onde audit trails, rastreabilidade e planeamento documentado são requisitos de conformidade
- Empresas multi-produto onde diferentes unidades de negócio precisam de coordenar lançamentos
- Organizações com baixa maturidade de engenharia onde as equipas precisam de mais estrutura, não menos (embora eu argumentasse que há melhores pontos de partida do que o SAFe)
Mas se és uma startup ou scale-up com 20-50 engenheiros e 3-6 equipas, quase certamente não precisas disto.
O Princípio Por Trás de Tudo Isto
O princípio subjacente é simples: a coordenação deve ser tão leve quanto a complexidade exige e não mais pesada. Começa com o processo mínimo viável. Se quebrar, adiciona estrutura. Se aguentar, deixa-o como está.
A questão certa não é "que processo devemos adotar?" É "qual é a quantidade mínima de coordenação que nos permite lançar sem quebrar o trabalho uns dos outros?"
Na Conectia, as equipas que construímos para startups europeias e americanas frequentemente juntam-se exatamente nesta fase de crescimento — três a cinco squads a descobrir como coordenar. Os nossos engenheiros sénior LATAM têm experiência a trabalhar em configurações distribuídas e multi-equipa, e trazem padrões práticos de coordenação que não requerem adotar uma framework empresarial para funcionar.
A crescer a tua organização de engenharia e precisas de engenheiros que saibam trabalhar em equipas? Fala com um CTO — os nossos engenheiros sénior integram-se em configurações multi-squad e trazem experiência de coordenação desde o primeiro dia.
