Sprint Review: A cerimônia esquecida que pode mudar tudo

Não vou falar por todo mundo, mas quase nenhum dos lugares por onde passei que aplicavam Scrum faziam a Sprint Review. Alguns até tinham uma reunião com esse nome mas na prática discutia outras coisas e não servia ao propósito da Review.

Que propósito seria esse? De acordo com o Scrum Guide “O objetivo da Sprint Review é inspecionar o resultado da Sprint e determinar os próximos passos pro futuro. O time apresenta o trabalho que foi feito e se discute o progresso rumo à meta do Produto”

O trecho chave aqui é “Apresenta o trabalho feito”. Não é discutir o que deu errado, não é dizer que tá tudo pronto e só falta a revisão de código pra subir, é mostrar o que tá pronto. A regra que gosto de usar: É proibido mostrar Figma, Miro, PPT, ou ambiente de teste. O time abre o site/produto mostrando cada história do board no ar, visível pros usuários - e de preferência enviando eventos de medição pros dashboards de produto, afinal o resultado de um produto é medido pela resposta do público. Sem medir essa resposta, entregar o código pode não surtir efeito algum.

E por que ter uma cerimônia só pra oficializar o que já tá acontecendo? Realmente a Review não faz diferença nenhuma na Sprint entregue. Mas fará nas Sprints futuras.

Muito se fala em autonomia e como é algo desejado nos grupos de trabalho. Isso não acontece simplesmente falando no assunto, mas sim fomentando práticas que estimulam esta autonomia, dando segurança e senso de responsabilidade aos times. É por isso que não adianta falar. Quando alguém manda você trabalhar, mesmo que a ordem seja “Tenha autonomia”, o efeito é o contrário. As pessoas vão tentar fazer algo pra agradar quem tem poder. A consequência de longo prazo de ter um time focado em agradar stakeholder é que o foco fica em agradar e não na entrega. As duas coisas no início estão de mãos dadas, mas vão se afastando. Se o time descobrir que dizer ou esconder algo agrada mais do que a entrega em si, pode ter certeza de que farão isso. E isso não será traço de um time ruim, pelo contrário. Será um time fazendo muito bem exatamente o que se incentiva neles.

O que funciona então? Fazer o time se responsabilizar pela entrega. Aqui entra o real objetivo da Sprint Review. Quando o time mostra algo combinado no ar eles têm a chance de se orgulhar do que foi feito, ou também sentir o peso de não ter ainda conseguido botar no ar o que se comprometeu. Não há discussão, há apenas fatos sobre o andamento do trabalho na mesa. O único interesse é saber na prática o que realmente pode ser removido do backlog pra se decidir os próximos passos sem subjetividades. A política é removida do processo.

É por isso que botar placares eletrônicos mostrando a velocidade atual dos carros que passam tem eficácia comprovada em fazer os motoristas dirigirem na velocidade limite, mesmo quando é claro que não há ali multa automática. O próprio motorista, quando é obrigado a se deparar com um fato sobre o que está fazendo, tem a oportunidade de se corrigir pra fazer melhor. O ganho é a sensação de fazer a coisa certa e ser um bom motorista. Esse é um incentivo mais poderoso a longo prazo que instalar punições que podem fazer o motorista diminuir a velocidade apenas onde ele sabe que existem radares e acelerar no resto do percurso.

O que eu vi toda vez que implementei a Review: A cada Sprint o time ia se responsabilizando mais pela entrega, ficando mais proativo, se mexendo pra resolver problemas, avisando rapidamente quando encontrava obstáculos. Ao entender que a entrega depende unicamente do que foi combinado na planning e não de explicações, o planejamento fica mais maduro e assertivo. Ao saber que não existe avaliação externa além de aferir se as tasks foram pro ar, o time fica mais seguro em botar 100% do foco nisso.

Então repassando as dicas pra uma Review que exorciza a política e aumenta o senso de dono dos times:

1. O formato da reunião é olhar os cards que estão em “Done” e o time mostra aquela história funcionando em produção

2. O PM aprova a entrega - ou mostra de acordo com o card porque não está de acordo - e pode tomar 3 ações:

   1. Dá o card como entregue

   2. Caso nada no escopo tenha mudado, só não deu tempo de terminar: Volta o card para o backlog com observações do que falta a serem inseridas na planning

   3. Caso tenham surgido novos escopos não previstos: Cria um novo card com tarefas de apoio e põe no backlog de acordo com a severidade/prioridade adequada

3. Não usar a Review pra reclamar, olhar feio, pedir justificativas em detalhes. Quanto mais objetiva for a reunião, mais tranquilo e seguro o time fica pra se autoavaliar.

O lugar para debater o que deu certo ou errado nos processos é na Retrospectiva. Confundir com a Review na minha vivência invariavelmente faz com que a Review se perca em discussões e explicações. Separar as duas passa a mensagem clara pro time: Uma coisa são as entregas, outra são os processos.

Nunca se esqueça: O time quer entregar. Times seguros e autônomos entregam mais.

Te convido a experimentar.

Este texto foi parte da Newsletter #1. Assine para receber conteúdos como esse semanalmente: https://fabio-produto-opentalent.beehiiv.com/subscribe

Quer mentoria, palestras ou contar comigo na sua liderança? Veja como trabalho aqui: https://produtoopentalent.com