Eu gosto de Ágil. Eu gosto de disciplina. Gosto de sistemas que são lançados e de sistemas que aprendem.
O que não gosto: tribos.
Nas últimas décadas, muitas equipes acamparam nos extremos de um espectro:
- As lojas tradicionais tratavam a otimização como virtude e a adaptação como risco.
- As lojas ágeis tratavam a adaptação como virtude e a otimização como traição.
Ambos perderam o foco.
Por adaptação quero dizer aprendizagem rápida e correção de curso sob incerteza.
Por otimização quero dizer confiabilidade e repetibilidade sob restrições.
O erro é tratar qualquer um deles como um modo operacional permanente.
A questão dos adultos é: o que deve dominar neste momento?
Esta é uma tensão a ser gerenciada, não um lado a ser escolhido.
Por que isso é importante agora (além do software program)
As equipes de software program vivem nessa tensão há anos.
Agora, mais indústrias atingem o mesmo muro – rapidamente.
As ciências da vida (Biotecnologia) fornecem exemplos claros. Ferramentas como CRISPR (edição de genes), AlphaFold (dobramento de proteínas em 3D) e outros modelos de descoberta assistidos por IA comprimem os ciclos iniciais.
As ferramentas baseadas em CRISPR ajudaram a investigação e a descoberta de alvos sobre a COVID-19, enquanto as tecnologias de plataforma, como o mRNA e os vetores virais, foram os principais facilitadores do cronograma de vacinação de um ano. O AlphaFold muitas vezes pode fazer em horas em um computador o que costumava levar meses ou anos no laboratório.
Usando essas ferramentas, as equipes podem explorar mais opções com mais rapidez. Isso soa como pura vantagem – até que você se lembre do outro lado da tensão: o trabalho posterior fica mais caro, mais restrito e menos indulgente.
O aprendizado mais rápido não take away restrições. Aumenta o custo de decisões desleixadas.
Portanto, a lacuna de capacidade muda. Não é mais “Podemos “fazer” Agile?” É: podemos gerenciar a tensão Adaptação ↔ Otimização propositalmente – com velocidade?
O que quero dizer com “dois modos”
Eu uso dois modos como uma abreviação prática. Não são filosofias. Eles são padrões operacionais.
Modo Explorar (adaptação dominante)
Objetivo: reduzir rapidamente a incerteza.
O modo Explorar trata o trabalho como uma série de hipóteses.
- Você executa ciclos curtos: hipótese → teste → sinal → decisão.
- Você mantém os custos baixos para poder mudar de rumo.
- Você protege a qualidade da evidência o suficiente para confiar no sinal.
O modo Explorar faz não significa caos. Isso significa que você otimiza o ciclo de aprendizagem.
Modo de exploração (otimização dominante)
Objetivo: reduzir a variação sob restrições.
O modo de exploração trata o trabalho como um sistema que você deve executar de forma confiável.
- Você aperta o processo.
- Você aumenta os limites de evidência.
- Você protege a segurança, a qualidade, a proteção e a rastreabilidade.
- Você ainda se adapta, mas apenas dentro de grades de proteção transparentes.
O modo de exploração faz não significa burocracia. Isso significa que você otimiza a confiabilidade.
Uma nuance importante: domínio, não pureza
Ambos os modos existem o tempo todo.
- As fases de exploração ainda precisam de otimização (tempo de ciclo, higiene de evidências, regras de parada).
- As fases de exploração ainda necessitam de adaptação (alterações disciplinadas, experiências controladas, exceções baseadas no risco).
O domínio mantém você fora da religião.
Um estado de ponte: “Expandir”
Usar as palavras explorar e explorar muitas vezes traz à mente o pensamento de Kent Beck
explorar–expandir–extrair. Essa conexão é útil.
Vejo a expansão como o estado-ponte onde um sinal promissor passa da aprendizagem barata para a evidência em escala.
Na expansão, você faz três coisas ao mesmo tempo:
- 1. Prova de escala (mais casos, mais quantity, mais ambientes)
- 2. Levantar restrições (qualidade, segurança, governança, disciplina de integração)
- 3. Reduzir a ambiguidade (limiares claros para o próximo compromisso)
A expansão é onde muitas organizações pagam a maior taxa de transferência, porque as equipes continuam explorando comportamentos enquanto o trabalho agora exige disciplina de exploração.
O imposto de transferência
A maioria dos programas não falha dentro de uma fase.
Eles falham nas costuras.
Eu chamo o custo oculto nas costuras de imposto de transferência:
- falhas de tradução (mesmas palavras, significado diferente)
- incompatibilidade de evidências (barras diferentes para “prova suficiente”)
- névoa de propriedade (muitos votos, muitos vetos)
- lacunas de rastreabilidade (ninguém pode reconstruir por que uma escolha aconteceu)
Se você quer velocidade, corte o imposto de transferência. É melhor do que “fazer o Agile com mais afinco”.
Um rápido desvio: por que a TI bimodal saiu pela culatra
Uma “solução” inicial para esta tensão foi a TI bimodal: colocar o trabalho exploratório numa by way of e a entrega estável noutra – frequentemente como unidades organizacionais separadas.
No papel parecia arrumado.
Na prática, transformou-se em tribos guerreiras. Um lado tornou-se o herói da inovação. A outra tornou-se a polícia de estabilidade. As decisões oscilaram entre eles, os impostos sobre transferências explodiram e os líderes tentaram gerir os conflitos em vez de conceber o trabalho.
A lição: você não pode terceirizar essa tensão para um organograma. A capacidade deve estar presente em cada pessoa que toma decisões – desde membros da equipe até executivos.
Um exemplo concreto: Sciex e integração inicial
Em 2004–2006 trabalhei com a Sciex, uma empresa de instrumentos de espectrometria de massa com certificação ISO. Uma falha no meio da execução de uma amostra pode arruinar um experimento e desperdiçar amostras insubstituíveis.
Depois de mais um ano trabalhando com equipes de software program, enfrentamos um projeto assustador: o desenvolvimento de um novo instrumento de especificação de massa.
Descobrimos que o grande assassino é a dívida de integração (imposto de transferência) – a dor que você acumula quando {hardware}, firmware e software program convergem tarde.
Os requisitos da ISO mantiveram a governança actual. Portanto, evitamos uma escolha falsa.
- Governança otimizada em termos de tempo, dinheiro e rastreabilidade.
- Execução adaptada à incerteza com ciclos curtos de suggestions e integração precoce.
Então, o Diretor de Desenvolvimento de Produto promoveu uma mudança simples:
- firmware entregue ao {hardware} em iterações, acompanhado pelo cronograma de testes do {hardware}
- uma vez que o {hardware} atingiu “função suficiente”, o software program se juntou para adicionar aplicativos – também em incrementos
- eles fizeram não aguarde uma placa digital totalmente preenchida para iniciar os testes de integração
Resultado:
- os testes de integração começaram mais cedo, então os problemas surgiram mais cedo e foram resolvidos mais rapidamente
- a integração permaneceu contínua quando o {hardware} mínimo existia, então o pico regular de recursos no ultimate do jogo desapareceu
- a comunicação melhorou porque todos os grupos participaram da integração, não apenas na fase de pânico
Isso é ajuste de dominância na natureza:
- discover cedo onde a incerteza permanece alta
- expandir à medida que as evidências aumentam e as restrições aumentam
- explorar uma vez que a confiabilidade é mais importante do que a criação de opções
Torne o domínio operacional: quatro mostradores
Se você quer domínio sem debates, use dials.
- Incerteza – o que você ainda não sabe
- Risco – o que quebra se você errar
- Custo da mudança – quanto custa um pivô em tempo, dinheiro e credibilidade
- Limite de evidência – quanta prova você precisa antes de se comprometer
Gire os botões, defina o domínio e projete o fluxo de trabalho correspondente.
Explorar dominante: ajuste o ciclo de aprendizagem
- tempo de ciclo curto desde hipótese → teste → sinal → decisão
- regras de parada claras (eliminar apostas fracas rapidamente)
- higiene de evidências (suposições, controles, notas reproduzíveis)
Duas falhas comuns: aprendizado lento e evidências confusas.
Expandir: dimensionar a prova e reforçar as restrições
- amostras maiores, ambientes mais amplos, mais pontos de integração
- crescente disciplina de governança
- limites explícitos para o próximo compromisso
Duas falhas comuns: falsas certezas e integração tardia.
Exploração dominante: adapte-se dentro das grades de proteção
- alterações disciplinadas, com gatilhos e justificativa limpa
- experimentos controlados (variância não acidental)
- rastreabilidade que você pode defender sob auditoria
Duas falhas comuns: teatro de conformidade e soluções alternativas ocultas.
Direitos de decisão: use DARE, não RACI
A rapidez e a responsabilização necessitam de direitos de decisão claros. Isto não é adoração hierárquica.
Muitas organizações buscam RACI:Responsável, Responsável, Consultado, Informado. Na prática, o RACI muitas vezes transforma decisões em lama de calendário e vetos educados.
Use DARE em vez disso: Decisores, conselheiros, recomendadores, partes interessadas na execução.
O DARE evita que a “liderança servidora” e a “auto-organização” (e seus primos: “equipes capacitadas”, “decisões descentralizadas”) caiam na anarquia suave: você pode dar voz a mais pessoas sem dar a todos um voto.
- Decisores: os únicos votos; frequentemente um (mas não exclusivamente)
- Conselheiros: voz forte, sem veto
- Recomendadores: opções de construção e compensações
- Partes interessadas na execução: execute a chamada e revele as restrições antecipadamente
O DARE trabalha em todos os níveis – desde a equipe de produto até a equipe do CEO – porque o padrão permanece o mesmo:
- decidir(ões) claro(s)
- entrada actual
- opções reais
- compromisso rápido
O DARE evita que a autonomia se transforme em consenso por exaustão.
Adaptação: trate-a como design operacional
Muitas equipes tratam a alfaiataria como perda de peso: comece com um grande método, corte etapas, espere que a velocidade apareça.
Isso é desmontagem.
A verdadeira alfaiataria significa design para caber:
- manter restrições que protejam a segurança, a qualidade e a rastreabilidade
- manter práticas que protejam a velocidade de aprendizagem e a criação de opções
- costuras de design para que os modos não briguem entre si
A alfaiataria também exige julgamento, e o julgamento permanece escasso. Você pode comprar ferramentas e modelos. Você não pode comprar discernimento em grande escala.
O take-away
Pare de vender “Ágil versus Tradicional”. Essa história vende o problema.
Projeto para a tensão:
- tratar explorar, expandir, explorar como um conjunto de padrões de dominância
- gire os mostradores de propósito
- reduzir o imposto de transferência nas costuras
- tratar a alfaiataria como design operacional
Onde você paga o imposto de transferência mais alto hoje – e qual botão você ligaria primeiro?