O PO começa a Planning e mostra para o time uma lista de itens que ele priorizou no backlog do produto. O primeiro item é a criação de uma tela onde o usuário irá cadastrar seus dados pessoais. O time pergunta sobre a máscara e formato de cada campo, se precisa consultar a informação em algum lugar, se o layout está pronto. Alguns desenvolvedores reclamam que os detalhes não estão descritos claramente na história, e o PO complementa. O time pontua: 8 pontos. Podemos seguir para a próxima história do backlog.
Agora você pode escutar o conteúdo. Dê o play!
Quantos problemas você vê com esta situação? Se você está acostumado a trabalhar com um time tarefeiro, talvez não veja nenhum. Mas há muitos pontos de melhoria aqui, e algumas disfunções que podem causar verdadeiros desastres em um produto.
Um time tarefeiro é aquele que aplica todo o seu foco na lista de tarefas a executar. Ele inclusive pode ter o costume de criar histórias técnicas, muitas vezes de surpresa durante a Planning, porque “é importante”. É um time que visa a eficiência mais que a eficácia, pois está muito preocupado com o throughput e a velocidade, mas nem tanto com o que está sendo entregue de valor para o produto. Este time delega ao PO de forma exclusiva o domínio, o entendimento e a decisão sobre o que vai ou não resolver o problema do consumidor. As hipóteses de solução do problema ficam a cargo do PO e, com sorte, do designer. Ao time cabe apenas viabilizar tecnicamente o que quer que o PO tenha decidido que deve ser feito.
Muito falamos de mindset ágil, mas ao encontrar um time tarefeiro, parece que este mindset cessa no momento em que o time descobre que vai ter que queimar o coco pensando em como resolver um problema do usuário. Este time falha em ver que as melhores soluções emergem de times multidisciplinares (não, o PO não é um time multidisciplinar), e que resolver um problema realmente importante vai exigir que todas as cabeças do time pensem juntas. Em vez de assumir esta postura, o que vemos é uma transferência de responsabilidade e esforço cognitivo para o PO. Enquanto isso, os membros do time de desenvolvimento – muitas vezes incluindo também os designers – assumem a postura do “só cumpro ordens”, “sou dev, não sou pago pra isso”, “preciso do escopo da história fechado”, “foi assim que o PO pediu”.
O resultado é um produto pobre, com uma probabilidade muito menor de sucesso.
Então como podemos tratar estas disfunções e transformar um time tarefeiro em um time de produto?
Problemas, não soluções
Ao criar uma história, devemos evitar definir a solução. Leve a mesma para o time e converse, usando os 3 Cs sugeridos por Ron Jeffries: cartão, conversa, confirmação. Lembre que o objetivo da história é começar uma conversa, e não ser prescritivo. Usamos histórias de usuário para que o time consiga empatizar com o consumidor do produto e ajudar a resolver seu problema, então explore isso ao máximo com o time e aproxime-o da experiência e das dores do usuário. O time deve ser capaz de responder à pergunta “Como o produto que eu estou fazendo ajuda as pessoas?”, expressando seu propósito sem pestanejar.
Refinamentos
Para POs mais experientes isso pode não ser novidade, mas não é incomum ver times que não fazem Refinamento. E, geralmente, estes mesmos times têm Plannings extremamente extensas e desgastantes.
O Refinamento é um momento que ocorre durante o tempo de sprint, olhando para os itens que estão no topo do backlog e provavelmente serão absorvidos pelo time de desenvolvimento na próxima sprint.
O objetivo do processo de refinamento é deixar as histórias preparadas conforme a definição de preparado (definition of ready). No entanto, é possível que, durante o Refinamento, o time descubra que não tem todas as informações para definir qual será a solução para aquela história. E isso é ótimo!
Imagina se você fosse esperar para descobrir isso na Planning?
Durante o Refinamento, é esperado que o time aborde algumas histórias por vez. Tentar abordar todas as histórias que entrarão na próxima Planning pode gerar uma reunião muito cansativa, então é válido pensar em reuniões rápidas para debate que sejam recorrentes ao longo da sprint. Exemplos: para sprints de 2 semanas, um refinamento de 1h por semana. Para sprints de 1 semana, 2 refinamentos de 1/2h por semana.
É importante que, durante o Refinamento, o time:
- verifique se todos entendem o problema a resolver, o valor a agregar para o produto, o teste de hipótese a ser feito e os motivos que levaram à priorização daquela história;
- ajude a complementar as informações da história, tornando-a mais rica;
- discuta a solução para aquele item de backlog, chegando em um consenso;
- identifique se existe a necessidade de envolver mais gente para discutir a solução, e convide estas pessoas para o próximo Refinamento;
- verifique se ainda há impedimentos ou informações adicionais a coletar – e trate isso assim que possível, para que a história fique preparada;
- estime a história em relação ao esforço, pois ele será usado como critério de priorização do PO.
O Refinamento não deve ser usado, todavia, para quebrar tarefas ou fazer POCs. Ele também não deve ser tratado como uma tarefa pontuada na sprint, dado que ele apenas dilui durante a sprint uma discussão que, se não for feita, terá que acontecer de uma forma muito pior na Planning.
Dinâmicas de consenso
Esta é uma excelente forma de quebrar a expectativa que o time tem de receber o escopo pré-definido do PO. Usando dinâmicas de consenso, você pode apresentar um problema e omitir temporariamente a solução que você pensou para ele, enquanto o time busca formas alternativas que você mesmo pode não ter cogitado. Isso trará uma grande riqueza para as hipóteses de solução do seu produto e aproximará o time da sensação de pertencimento no que tange ao produto.
Independente se você consegue refinar seu backlog com a participação exclusiva do seu time, ou se você precisa de mais gente (outros times, consultores, stakeholders) presentes, é importante ter a consciência que estamos tentando empoderar o time para resolver um problema. Para isso, é necessário buscar um equilíbrio entre as pessoas que têm uma postura de maior liderança (seja por natureza ou por cargo) e as pessoas que não se sentem tão confortáveis segurando o leme do barco.
Além disso, as aparentes concordâncias exigem um cuidado extra. Perguntas como “todo mundo entendeu?” não ajudam, porque nossa tendência é sempre achar que entendemos, e que todos têm a mesma visão que a gente. Colocar todo mundo para escrever individualmente o que entendeu num post-it e depois comparar as respostas e chegar em um consenso, para então rabiscar no quadro o resultado faz toda a diferença.
Dual-track scrum
O conceito criado por Jeff Patton tem como objetivo dar clareza ao processo de descoberta contínua do produto. Parte do time está focada no desenvolvimento dos itens de backlog que já estavam preparados e fizeram parte da planning, enquanto O PO, o UX e um ou mais membros do time de desenvolvimento dedicam parte do seu tempo a “descobrir” o que deverá ser construído a seguir, prototipando e validando hipóteses, que gerarão itens de backlog preparados para a próxima sprint.
Façamos uma tentativa de adaptação para explicar a ideia de uma forma simples e prática:
Esta é uma sprint “comum” versus uma sprint em dual-track scrum:
Os percentuais aqui são fictícios, e no máximo uma sugestão. Cada time acaba encontrando sprint a sprint o que funciona melhor.
Este é o conteúdo abordado em uma track de descoberta:
Parte do esforço da sprint será usado para entender se o que já entregamos resolveu o problema que estamos tentando resolver. Iremos (in)validar nossas hipóteses e aprender de acordo com as métricas que definimos anteriormente. Vamos coletar feedback e entender o que podemos melhorar. Isso nos dará insumos para ajustar ou alterar tanto as histórias que estavam priorizadas quanto descartar ou criar novos itens. Faremos testes com prototipação, pesquisa de guerrilha, conversas com os usuários e o que mais for útil para a melhor tomada de decisão possível em relação a quais serão nossas próximas hipóteses de problemas e de soluções.
Mindset
Por último, é necessário que continuemos sempre cobrando o mindset correto do time. Sem uma peer pressure saudável, a tendência é que o time retorne a uma postura confortável e tarefeira, por mais que tenham visto como é prazeroso e motivador se apaixonar pelo problema e fazer parte da solução. Afinal, estamos lutando contra décadas de condicionamento focado em execução de mais coisas mais rápido, e não na busca da coisa certa a construir.
Curtiu? Quer saber mais sobre esse assunto? Veja os links abaixo:
- Faça o nosso treinamento de Certified Scrum Product Owner (CSPO).
- Leia também muitas outras dicas no Livro Scrum do Rafael Sabbagh
- Leia os posts sobre:
