O que é Dual Track Agile?

A ideia de integrar descoberta e entrega evoluiu em comunidades de produto e desenvolvimento ágil. Marty Cagan publicou em 2012 uma explicação de Dual-Track Agile como colaboração contínua entre produto, design e engenharia. Jeff Patton aprofundou a crítica à interpretação das trilhas como dois times ou duas fases rígidas.

Cagan passou a preferir os termos Continuous Discovery e Continuous Delivery, para destacar os princípios em vez de um desenho de processo. Não há um único criador da prática. A origem relevante é a tentativa de aprender rapidamente o que vale construir enquanto o time continua entregando e observando resultados.

A trilha de descoberta reúne perguntas: que problema merece atenção, para quem, que alternativas existem, o que pode falhar e que evidência mudaria a decisão? A trilha de entrega transforma decisões em software ou serviço utilizável, com qualidade, implantação e acompanhamento. A primeira não é uma fábrica de especificações para a segunda. Pessoas que constroem participam da descoberta e pessoas de produto acompanham a entrega e o uso real.

Jeff Patton insiste em duas trilhas, não dois times. Produto, design e engenharia podem coordenar o trabalho de descoberta, mas excluir Desenvolvedores dela tende a gerar soluções inviáveis ou mal compreendidas. Da mesma forma, uma pessoa de produto não deveria simplesmente passar um documento para engenharia e desaparecer até o lançamento. Colaboração cedo reduz tradução, espera e retrabalho.

Descoberta é trabalho com risco. Uma hipótese pode falhar em desirabilidade, usabilidade, viabilidade técnica ou sustentabilidade para a organização. Não é necessário usar sempre entrevistas ou protótipos. Às vezes uma conversa com suporte revela a causa de um problema; em outras situações é preciso uma prova técnica ou teste de uso. Escolha o experimento menor que possa informar uma decisão relevante.

Entrega também ensina. Um protótipo pode sugerir que uma solução ajuda, mas somente o produto em uso mostra efeitos de operação, adoção e comportamento ao longo do tempo. Por isso uma entrega pode ser também um experimento. O time define sinais de resultado, acompanha o uso e volta à descoberta quando a evidência contradiz a hipótese inicial. A ideia não sai da trilha de descoberta com carimbo de “validada para sempre”.

Fluxos paralelos não exigem cadências idênticas. Uma investigação pode durar horas, outra várias semanas. Itens de entrega também variam. O trabalho deve ser visível para não sobrecarregar as mesmas pessoas nem criar fila de descobertas que nunca serão usadas. Limitar trabalho em andamento e escolher perguntas relacionadas às decisões próximas pode ajudar a manter equilíbrio.

O modelo pode conviver com Scrum. O Scrum Guide não prescreve Dual Track nem duas Sprints. Uma equipe pode investigar hipóteses durante a Sprint enquanto entrega um Incremento. A Meta da Sprint continua orientando o trabalho. Também não há necessidade de criar uma Sprint de discovery separada antes de uma Sprint de delivery; isso reproduz uma sequência de fases e pode atrasar feedback.

Quando um item entra em entrega? Não existe uma fórmula universal. O time precisa compreender o resultado esperado, principais riscos e um recorte que possa ser construído responsavelmente. Algumas dúvidas permanecem e serão resolvidas ao implementar. Outras, como falta de evidência de um problema ou restrição técnica decisiva, merecem experimento antes. Um checklist rígido de passagem pode tornar discovery uma burocracia que apenas prepara tickets.

Mantenha decisões rastreáveis. Para cada aposta relevante, registre problema, hipótese, evidência disponível, opção escolhida e sinal de sucesso. Uma nota breve basta quando a equipe conversa continuamente. O registro evita que um experimento esquecido seja apresentado depois como prova de algo que nunca testou. Também permite retomar alternativas descartadas quando o contexto mudar.

Product Discovery aprofunda a disciplina de investigar oportunidades e soluções. Dual Track trata especificamente de sua convivência com delivery no cotidiano do time. Um MVP pode ser uma entrega usada para testar hipótese real, mas não é obrigatório nem equivale à menor quantidade de funcionalidades por definição.

Atenção ao resultado. Uma equipe pode estar muito ocupada nas duas trilhas e ainda não melhorar o produto. Conte o que aprendeu e entregou, mas observe também mudança para usuários e negócio. Se uma hipótese promissora demora meses para chegar ao uso, reveja a entrega. Se várias funcionalidades são lançadas sem evidência sobre o problema, reveja a descoberta.

Imagine um time hipotético que mantém um serviço de agendamento. O objetivo é reduzir desistências antes da confirmação. Na entrega, 4 pessoas corrigem uma falha conhecida: o horário selecionado desaparece após voltar de uma tela. Ao mesmo tempo, pessoas do mesmo time investigam por que parte dos usuários abandona a escolha de horário. Os números são apenas do exemplo.

A descoberta começa com dados de abandono e conversas com usuários. O grupo suspeita que a duração da consulta não está clara. Cria duas versões simples de explicação e observa tarefas com 6 pessoas. A maioria entende uma versão, mas aparecem dúvidas sobre cancelamento. Isso informa uma próxima pergunta, não prova que uma nova tela aumentará conversão em produção.

Antes, o time recebia uma lista de funcionalidades decididas antecipadamente e só via resultado depois de lançar todas. Depois, a correção conhecida segue para entrega enquanto a hipótese sobre informação é investigada. Quando decide construir um recorte, produto, design e engenharia já conhecem o problema e as limitações. O lançamento é acompanhado por comportamento real e mensagens ao suporte.

O grupo pode descobrir que a nova explicação não altera desistência ou que a causa principal é a indisponibilidade de horários. Nesse caso, volta à investigação sem chamar o experimento de fracasso. O valor das trilhas paralelas é manter trabalho útil avançando enquanto perguntas relevantes são respondidas, e permitir que a entrega gere novas perguntas.

Cursos K21 recomendados