O que é Dual Track, e por que não são duas equipes

Dual Track é a prática de rodar duas trilhas em paralelo dentro do mesmo time: descoberta, que responde se vale a pena construir algo, e entrega, que constrói com qualidade de produção o que já foi validado. As duas correm ao mesmo tempo, de forma contínua.

Não são duas fases. Não são dois times. E é aí que a maior parte das adoções se perde, porque o nome sugere separação e a separação é justamente o que anula o benefício.

Quando descoberta e entrega viram etapas em fila, o que existe é cascata com vocabulário novo: alguém descobre tudo, escreve, e passa para quem constrói.

De onde veio

A ideia é mais antiga que o termo, e a atribuição costuma vir errada em material em português.

Em 2005, Lynn Miller, diretora de desenvolvimento de interface na Alias, apresentou um trabalho descrevendo trilhas paralelas e interligadas de design e desenvolvimento. Em 2007, Desirée Sy, então na Autodesk, publicou o artigo que descreve o processo com duas trilhas operando de forma autônoma e concorrente: uma cuidando de necessidade do usuário e protótipo, outra finalizando arquitetura e código.

Em 2012, Marty Cagan e Jeff Patton passaram a falar de "dual-track scrum", com as trilhas de descoberta e entrega, onde a saída de uma é a entrada da outra.

Vale registrar que Patton escreveu depois um texto cujo título já resume o problema: dual track development is not duel track. Não são duas trilhas competindo, nem se revezando. Correm juntas.

O que acontece em cada trilha

A trilha de descoberta existe para reduzir incerteza antes de gastar engenharia. Ela produz decisão e evidência, não código de produção. Entrevista, protótipo, teste com usuário, prova de conceito técnica, análise de dado existente.

Cagan organiza essa incerteza em quatro riscos, e a formulação é útil porque separa perguntas que times costumam confundir:

• Valor. As pessoas querem isso, o suficiente para usar ou pagar?
• Usabilidade. Elas conseguem usar?
• Viabilidade técnica. Conseguimos construir e sustentar?
• Viabilidade de negócio. Isso funciona para a empresa, considerando custo, jurídico, marca, suporte e canal de venda?

Os quatro precisam ser respondidos, e quase nunca pela mesma pessoa. É por isso que a descoberta funciona melhor com produto, design e engenharia juntos: descoberta feita só por produto valida valor e descobre a inviabilidade técnica depois, na entrega, quando corrigir já custa caro.

A trilha de entrega constrói o que passou pela descoberta, com a qualidade que produção exige: teste, arquitetura, segurança, observabilidade, documentação. É a trilha que tem cadência, e é onde Scrum ou Kanban operam.

A ligação entre as duas é o que importa. A descoberta não entrega um documento no fim de um ciclo. Ela alimenta a fila da entrega item por item, à medida que cada um fica validado.

O erro que quase todo mundo comete

Existem três variações do mesmo erro, e vale reconhecer cada uma.

Dois times. Um grupo de descoberta e um grupo de entrega. Cria passagem de bastão, e passagem de bastão perde contexto. Quem construiu não participou da decisão, então não sabe o que era essencial e o que era detalhe. Na primeira dúvida, adivinha.

Duas fases. Uma Sprint de descoberta, depois uma Sprint de entrega. É cascata em pedaços menores. O time descobre por duas semanas, constrói por duas semanas, e nenhuma das duas trilhas está contínua.

Descoberta como fase inicial do projeto. Descobre-se tudo no começo, e depois só se executa. É o modelo que o Dual Track existe para substituir, porque o aprendizado da construção não volta para a decisão.

O sinal de que a coisa está funcionando é chato de aceitar: o backlog de entrega nunca deveria estar cheio de itens não validados. Se está, a descoberta não está acompanhando, e o time está construindo com base em suposição.

Como isso se encaixa com o que já existe

Aqui o Dual Track ajuda a organizar um repertório que costuma ser apresentado solto. Ele não é um método novo que substitui os outros, é o arranjo que diz onde cada um opera.

Repare que os formatos de descoberta que existem são quase todos eventos: uma semana de Design Sprint, uma semana de Lean Inception. Eles respondem uma pergunta e terminam.

O Dual Track é a outra coisa: um modo permanente de operar, em que a descoberta nunca para. Os eventos continuam úteis, mas como técnica dentro da trilha, para perguntas grandes. A descoberta do dia a dia é menor e mais frequente: uma conversa com três clientes, um protótipo de duas telas, uma verificação técnica de meio dia.

E vale a ligação com o Lean: construir algo que ninguém usa é superprodução, o primeiro desperdício da lista de Ohno. A trilha de descoberta existe para atacar exatamente esse desperdício, que em tecnologia é o mais caro e o menos visível.

Onde isso trava em organização grande

A dificuldade não é entender o modelo. É a forma como a organização mede e financia trabalho.

Capacidade contada em entrega. Se a métrica do time é quanto ele entrega por Sprint, o tempo de descoberta aparece como capacidade perdida. Ninguém vai investir metade da semana em algo que a planilha registra como não produzido.

Orçamento aprovado por escopo. Quando o investimento é liberado contra uma lista de funcionalidades, a descoberta fica sem função: o escopo já foi decidido na aprovação. A trilha só faz sentido quando o time tem permissão para concluir que um item aprovado não deve ser construído.

Engenharia fora da descoberta. É o mais comum e o mais silencioso. Como o tempo de quem constrói é caro, a organização o poupa da descoberta. O resultado é decisão sem informação técnica, e a conta chega na entrega.

Na minha visão, o Dual Track é menos uma prática de time e mais uma escolha de governança. Um time pode organizar as duas trilhas sozinho no nível operacional, mas não consegue sustentar isso se a única coisa medida for volume entregue.

E existe um teste simples para saber se a descoberta é real na organização: com que frequência um item aprovado é descartado depois da descoberta? Se a resposta for nunca, a trilha existe para confirmar decisão, não para tomá-la.

Vale para todo time?

Não, e é honesto dizer.

Dual Track pressupõe incerteza sobre o que construir. Time que atende demanda regulatória, integração contratada ou correção de sistema existente tem pouca coisa a descobrir: o que fazer já está definido por fora, e o desafio é de execução.

Faz sentido onde o time tem espaço para decidir o que construir e onde errar essa decisão é caro. Ou seja, em produto.

Na sua organização, o time que constrói participa da decisão sobre o que construir, ou recebe a decisão pronta e responde pelo prazo?