Muitas empresas que passam por transformações ágeis já querem começar utilizando Métodos Ágeis em escala. Para tal, adotam frameworks como SAFe e outros. Entretanto, trabalhar em escala pode ser difícil e complexo, pois todos os problemas que ainda não foram resolvidos para um time, agora são multiplicados para todos os times e elevados ao quadrado para cada dependência entre eles.
A Lei de Conway
Melvin E. Conway percebeu logo cedo que a complexidade daquilo que a empresa desenvolve está relacionada à estrutura da empresa. Seu corolário, baseado no artigo “How do Committees Invent?”, publicado em 1968.
“Qualquer organização que projeta um sistema (amplamente definido) produzirá um design que espelha a estrutura de comunicação da organização.“
Lei de Conway em termos práticos
Imagine a seguinte hierarquia:
A Presidência quer criar um sistema para que os diversos interessados (internos e externos) acompanhem em tempo real o envio de cargas contratadas pelos clientes. A Unidade de Desenvolvimento fará a aplicação web e API. Já a Unidade de Banco de Dados define como os dados são armazenados. Ainda na TI, a Unidade de Experiência de Usuário (UX) projeta as telas e jornada dos interessados. Por fim, a Unidade de Logística Terrestre fornece os insumos necessários para construir os sistemas.
A Lei de Conway diz que a construção desse desenvolvimento refletirá essa estrutura. Logo, como consequência, o sistema provavelmente será modularizado e segmentado conforme essa estrutura. Isso significa que a arquitetura técnica refletirá a divisão organizacional. Obviamente, os atrasos ou dependências entre unidades (por exemplo, se a unidade de Banco de Dados mudar algo, os desenvolvedores precisam esperar) podem se refletir diretamente em gargalos no sistema. Outra possibilidade é que a experiência do usuário pode ser afetada se houver desalinhamento entre as equipes de UX, desenvolvimento e logística. Todos tendem a trabalhar de forma independente resolvendo a sua parte.
O problema piora se você subdividir os times. Por exemplo, os desenvolvedores são divididos em times de Back-end e front-end. Ou time de barramento, baixa plataforma e alta plataforma e por aí vai.
Times multidisciplinares
Não é à toa que o Scrum bate tanto na tecla de times multidisciplinares. Se dentro de uma equipe você tiver todos que precisam para realizar a entrega, melhor será o resultado, pois a Lei de Conway continua a atuar, porém, agora, todos os que precisam estar no time para realizar a sua entrega estão juntos e refletem essa realidade na construção de sistemas. Então, sempre que possível, reorganize equipes em torno de produtos, não de funções. Isso reduz transferências e mal-entendidos, além de promover ownership completo.
Dica do LeSS
Um framework interessante que fala sobre essa questão é o Large Scale Scrum (LeSS). Ele informa que devemos priorizar sempre Feature Teams (Times de Funcionalidades) em detrimento de Component Teams (Times de Componentes).
Feature teams são equipes multifuncionais que conseguem entregar uma funcionalidade completa do sistema por conta própria. Elas não dependem de outras equipes para concluir uma entrega, pois reúnem todas as competências necessárias — como backend, frontend, banco de dados e UX. Isso permite que tenham autonomia, entreguem valor direto ao usuário final e reduzam a necessidade de repasses entre times. O trabalho flui melhor, o feedback chega mais rápido e o foco permanece no que realmente importa: resolver o problema do cliente.
Já os component teams são especializados em partes técnicas específicas, como a camada de banco de dados, o frontend ou as APIs. Embora ofereçam uma profundidade técnica maior em cada área, não conseguem entregar nada completo sozinhos. Sempre dependem de outras equipes para que algo chegue ao usuário. Isso gera uma cadeia de dependências, muitos repasses, atraso na entrega e um esforço maior de coordenação. O foco deixa de ser o valor final e passa a ser a eficiência interna de cada pedaço.
Por isso, o LeSS recomenda com clareza: prefira feature teams. Eles favorecem a entrega contínua de valor, reduzem a complexidade organizacional e mantêm o cliente no centro da solução. É uma escolha que melhora tanto o produto quanto a forma de trabalhar.
Quando o Time Multidisciplinar não é possível
Nem sempre conseguimos ter todos os que precisamos no nosso time, logo precisamos de outras alternativas para resolver esse problema.
Quadro de Coordenação
Uma das coisas mais importantes é identificarmos essas dependências entre times diferentes e começarmos a controlá-las. Como já escrevi aqui algumas vezes, precisamos mapear o Fluxo de Trabalho ponta a ponta. Desde o início até a entrega na mão do cliente.
Infelizmente, muitos times têm resistência a isso, pois acreditam que depois que acabaram a sua parte, agora é problema do outro. Lembre-se daquela famosa frase do filme Tropa de Elite em que o comandante falava que certa parte do corpo pertencia ao ‘aspira’ (sic).
Um quadro de coordenação pode te ajudar nesse momento. Ele funciona de uma forma similar ao do time, porém mapeia o fluxo de trabalho ponta a ponta com todas as dependências.
O ideal é que os itens nesse quadro de coordenação não tenham a mesma granularidade dos itens no quadro do time. Por exemplo, enquanto um time mapeia os detalhes de implementação, “criar tabela XPTO”, “Solicitar alteração de XYZ”, “Avaliar viabilidade de 123”, o quadro de coordenação tenha itens em alto nível: “Sprint 001 do Produto X”, “Funcionalidade ABC do Produto Y” etc.
Perceba que o quadro de coordenação tem itens um tanto mais “genéricos” do que o quadro do time e as etapas refletem exatamente as dependências entre os times. Todavia, tenha cuidado, pois um quadro de coordenação não chega a ser um quadro estratégico que acompanha o portfólio da empresa.
Infelizmente o mapeamento em nível de coordenação é interessante, mas por si só não resolve o problema.
Cadência de Comunicação
Se as dependências são mantidas, o ideal é que existam pontos de contato para que os times possam alinhar o que estão fazendo e evitar desconexões e incompatibilidades. O Kanban sugere as cadências (reuniões):
- Workflow Replenishment Meeting (Reunião de Reabastecimento do Fluxo de Trabalho) que discute quais são os próximos itens de trabalho que entram no fluxo de trabalho
- Workflow Kanban Meeting (Reunião Kanban de Fluxo de Trabalho) que são discussões sobre como o trabalho combinado está sendo realizado.
- Flow Review (Revisão do Fluxo) que funciona como uma espécie de retrospectiva conjunta.
- Blocker Clustering (Agrupamento de Bloqueadores) para tratar as causas de itens que estão ficando bloqueados no fluxo de trabalho.
O quadro de coordenação é muito útil nesses momentos, pois ele servirá de guia e mapa de discussão de todas essas reuniões. As ferramentas atuais como Jira, Taiga, Business Map, permitem essa visualização em diferentes níveis.
Políticas Explícitas
Outra coisa que ajuda muito times com forte dependência, são políticas explícitas claras de convivência entre eles. Essas políticas podem descrever:
- Prioridade e ordem de atendimento
- Prazos
- Contratos de interface (API, Bancos, Formatos de Dados, Padrão de Nomenclatura etc.)
- Tipos de Serviços Prestados por cada time
- Política de “fura-fila” (expedite).
Não deixe nada subentendido, tudo deve ficar claro para todos.
Reduza silos e incentive a empatia
Uma tática que costuma a funcionar bem é o job shadowing (acompanhamento de trabalho). Por exemplo, um desenvolvedor de software acompanha um analista da logística por um dia.
Outra técnica que ajuda a trazer empatia pelo trabalho dos outros são as demissões abertas de atividades-chave. Com isso, os times vêem o impacto do trabalho do outro. O grande benefício é fortalecer a visão de produto e criar senso de propósito compartilhado.
Não escale
O LeSS, Scrum at Scale (S@S), até mesmo o Pacote de Expansão do Guia do Scrum (Scrum Guide Expansion Pack) fazem uma recomendação importantíssima:
SE POSSÍVEL, NÃO ESCALE.
Não é que eles sejam contrários a trabalhar em escala, inclusive eles foram criados com esse intuito. Todavia, reconhecem o desafio que é trabalhar em escala. Você sempre precisará de mais coordenação, mais reuniões, mais alinhamento e fatalmente suas entregas serão mais lentas. Se possível, deixe os times o mais ponta a ponta e o mais independentes possíveis.
Algumas dicas:
1. Escalar é caro — em tudo
Como já escrevi, quanto mais times você adiciona, mais reuniões são necessárias, mais gente precisa se coordenar, mais chances surgem de retrabalho, conflitos e atrasos. Escalar não multiplica produtividade, multiplica complexidade. Por isso, pense duas vezes antes de crescer horizontalmente.
2. Busque “times que aprendem” antes de criar novos times
Apressar a criação de novos times pode ser uma fuga para não lidar com limitações de aprendizado, priorização ou foco. Antes de escalar, verifique:
- O time atual está com foco claro?
- Estão priorizando o que realmente importa?
- O aprendizado está sendo usado para entregar mais com menos?
Se a resposta for não, o problema não é falta de time, mas falta de melhoria contínua.
3. Melhore a performance antes de adicionar capacidade
Muitas vezes, times não entregam mais não por falta de pessoas, mas por bloqueios, gargalos ou ruídos de comunicação.
Use práticas de Kanban, métricas como Customer Lead Time, WIP e Taxa de Chegada e Taxa de Entrega para identificar se há capacidade ociosa escondida que pode ser melhor aproveitada.
4. Reduza a complexidade do produto antes de expandir o time
No nosso livro Empresas Tradicionais: um castelo de mentiras, eu e o Rodrigo de Toledo falamos sobre uma mentira comum em projetos personificada pela Princesa Jáque. “Já que vamos pedir X, vamos pedir X’, Y, Z também. Logo, o produto fica cheio de penduricalhos que ninguém utiliza.
Às vezes, o problema não está na estrutura organizacional, mas no próprio produto: funcionalidades desnecessárias ou mal definidas, escopo inflado, arquitetura acoplada, excesso de dívidas técnicas etc. Antes de chamar mais gente, simplifique: Pode remover algo? Pode dividir o produto em micro-serviços ou módulos independentes menores? Pode investir em automações?
5. Teste escalar com times temporários, não permanentes
Se a expansão for inevitável, experimente criar ambientes escalados temporários com objetivos claros e prazos curtos. Por exemplo, entrega e estabilização da versão 3 até o final do próximo mês”. Isso evita criar estruturas pesadas demais e permite avaliar se realmente há ganho em escalar.
6. Evite o modismo do ágil em escala
Não escale apenas porque todo mundo está fazendo. Avalie se há real necessidade. Em muitos casos, times pequenos e bem alinhados entregam mais do que estruturas grandes e burocráticas.
7. Use princípios lean: maximize valor, minimize estrutura
Pergunte sempre: O que aconteceria se entregássemos isso com o time atual? O que precisamos parar de fazer para não precisar escalar?
Menos estrutura = menos ineficiência = mais foco no valor.
8. Prefira escalar por divisão de produto, não por função
Se precisar escalar, que seja dividindo produtos ou domínios, e não criando times especializados por tecnologia. Lembre-se sempre da Lei de Conway. Exemplo: Time A cuida do acompanhamento de carga. Já o Time B cuida da emissão de faturas. Evite separar por “back-end”, “banco de dados”, “UX”… isso cria componentes, não produtos.
9. Cuidado com o que você usa para escalar
Há frameworks e frameworks. Alguns são mais realistas e tentam manter a estrutura o mais enxuta possível. Por exemplo, o Kanban te ajuda a partir do ponto em que você está e conforme a necessidade surgir você implementa algumas de suas práticas. Já o LeSS e o Scrum at Scale tentam manter o foco total no produto e na manutenção de times multidisciplinares e enxutos.
Particularmente tenho algumas restrições quanto ao SAFe (Scaled Agile Framework). Não é que a sua teoria seja ruim, mas na prática ele tem sido utilizado como o meio de mudança para não mudar. Como ele já prevê uma estrutura e hierarquia de papéis completa, ele tende a burocracia, reforço de silos, preservação da estrutura, e como disse um colega recentemente: “aqui na empresa todo mundo virou mineiro. Toda hora tem um trem” (ele fala sobre o Agile Release Train e o Solution Train que são técnicas de entregas do produto no SAFe).
Conclusão
Escalar a agilidade não é o objetivo, é uma consequência. O verdadeiro foco deve estar em entregar valor com consistência, autonomia e aprendizado contínuo. Antes de pensar em frameworks, trens ou estruturas complexas, é essencial olhar para o básico: times pequenos, multidisciplinares, com foco no cliente e no fluxo de trabalho de ponta a ponta.
A Lei de Conway não é uma maldição, mas um alerta: a forma como nos organizamos define a forma como construímos nossos sistemas. Se queremos soluções simples, eficazes e centradas em valor, precisamos de estruturas organizacionais que favoreçam isso .
Portanto, antes de escalar, simplifique. Antes de criar novos times, melhore os que você já tem. E se for escalar, faça isso com consciência, propósito e o mínimo de desperdício possível. No fim das contas, a melhor estrutura ágil é aquela que atrapalha o mínimo e ajuda o máximo.
