Dual-Track Scrum

Quando encontro equipes de produto ágeis pela primeira vez, os membros da equipe geralmente estão numa situação em que sofrem com reuniões longas e frustrantes de Sprint Planning, porque os Backlog Items estão mal definidos e não foram compreendidos corretamente. A Velocity é lenta e o design é ruim, porque detalhes ainda estão sendo trabalhados durante o Sprint. Além disso, há muito desperdício e retrabalho a fazer, porque os Backlog Items não foram validados.

Lembre-se de que nosso objetivo principal é validar nossas ideias da forma mais rápida e econômica possível. Implementar uma ideia de produto e lançá-la no mercado é, fundamentalmente, a maneira mais lenta e cara de fazer isso.

O que é Dual-Track Scrum?

Por isso sou um grande fã de algo que é conhecido, entre outros nomes, como Dual-Track Scrum. Antes eu usava o termo "Discovery Sprints", mas isso dá a impressão de uma Discovery com tempo limitado e de uma serialização de fases.

Foi Jeff Patton quem me falou pela primeira vez sobre "Dual-Track Scrum". Prefiro esse termo porque ele destaca melhor o paralelismo entre Discovery e Delivery.

O Product Discovery Track trata de gerar Product Backlog Items validados o mais rápido possível. O Product Delivery Track trata de gerar software pronto para entrega.

Outro motivo pelo qual gosto tanto da metáfora das duas "trilhas" no Dual-Track Scrum é que frequentemente vejo pessoas que basicamente incorporam mini-cascatas em seu framework Scrum. O gerente de produto faz algum "trabalho de requisitos" e passa para um designer. Este então cria um design e gera seus artefatos (geralmente wireframes comentados), e depois tudo é entregue ao time de Delivery para desenvolvimento e testes.

Em contraste, o fluxo de trabalho no Dual-Track Scrum não é caracterizado por papéis individuais passando artefatos para a próxima etapa. Em vez disso, o Dual-Track Scrum é colaborativo – gerente de produto, designer e desenvolvedor líder trabalham lado a lado para criar e validar itens do backlog.

Os leitores dos meus artigos sabem o quanto considero importante o User Experience Design. No entanto, o ritmo e a velocidade do Scrum podem ser um problema para muitos times tradicionais de UX. Por isso sou um grande fã de Lean UX. Lean UX e Dual-Track Scrum foram feitos um para o outro. Em vez de nos concentrarmos em artefatos, na Discovery nos concentramos em protótipos e na validação desses protótipos. Outra vantagem é que esses protótipos funcionam como especificações para o Delivery.

O ponto mais importante, porém, é que a validação não acontece após o release como em um processo cascata, mas no Dual-Track Scrum realizamos a validação já durante a Discovery. Considerando o princípio de validar algo da forma mais rápida e econômica possível, muitas vezes conseguimos realizar a validação antes mesmo de escrever qualquer código – no espírito do lema "fake it before we make it", ou seja, fingir até que realmente funcione.

Conclusão sobre Dual-Track Scrum

Se a sua equipe está frustrada porque há muito desperdício e porque os resultados de negócio concretos estão demorando para aparecer, considere o Dual-Track Scrum. Talvez isso possa levar a uma melhor colaboração, iterações e validações mais rápidas e, assim, a um trabalho melhor.

Este texto foi retirado do blog de Marty Cagan e foi traduzido por nós para o português.

Estratégia empresarial vs. Estratégia de produto

Aprende mais sobre potenciais conflitos de estratégia no nosso artigo sobre a diferença entre estratégia empresarial e estratégia de produto.