Quem deve participar da reunião de retrospectiva da sprint?

Quando eu estava no quinto ano, comecei a fazer aula de saxofone (pode rir, mas todo mundo sabe que é o instrumento mais legal!). Meu professor era sensacional, um músico incrível que tinha parado de tocar em clubes de jazz para dar aula.

As lições que aprendi com ele foram para a vida toda: persistência, lidar com frustrações, prestar atenção aos detalhes. Porém, a melhor lição que ele me ensinou foi o valor da autoavaliação.

Certo dia, ele me pediu para comprar um gravador de fita K7 (é, faz tempo) e levar para a próxima aula. Na semana seguinte, ele gravou eu tocando uma música que estava aprendendo havia semanas. Assim que terminei, ele disse: “Muito bem, vamos ouvir”.

Fiquei desconcertado. Eu tinha acabado de tocar e sabia onde tinha errado. Por que precisava escutar o que eu tinha acabado de tocar?

Porém, aqui estava o problema: o que eu achava que tinha tocado não chegava nem perto do que eu de fato tinha tocado.

A gravação revelou todo tipo de erro. Notas desafinadas, ritmo descompassado, inícios errados. Estava horrível.

O gravador de fita logo se tornou meu objeto mais desprezado. No entanto, seu valor era claro, mesmo naquela época: Às vezes, você tem certeza de algo que não é verdade.

A nova perspectiva que você ganha na autoavaliação é a principal razão para você fazer reuniões de retrospectiva no Scrum se quiser que sua equipe Ágil continue atualizada e tenha sucesso.

O que é uma retrospectiva no Scrum?

Uma retrospectiva no Scrum é basicamente o seguinte: no fim de cada Sprint, o time se reúne para falar sobre o processo. O que funcionou? O que não deu certo? Como eliminar os obstáculos no próximo Sprint?

Antes de reunir todo mundo em uma sala e desabafar sobre as frustrações, é importante entender os papéis e as metas de uma retrospectiva no Scrum.

Um dos principais pilares da metodologia Ágil é a ideia da melhoria contínua na produtividade da equipe.

Todo Sprint deveria ser um pouco mais eficiente do que o último. A única forma de fazer isso é entendendo onde estão os pontos fracos do processo e implementando estratégias para superá-los.

Essa é a importância da retrospectiva no Scrum.

Michael Silvi é consultor sênior na Stride, uma empresa de consultoria em desenvolvimento de software em Nova York. Ele ajuda equipes a implementar a metodologia Ágil e Scrum há sete anos, enfatizando a estrutura formal (que vamos detalhar abaixo) para o sucesso na retrospectiva.

A seguir, ele compartilha sua expertise sobre a estrutura, os papéis e as metas de uma retrospectiva eficaz no Sprint.

Por que todo mundo ignora as retrospectivas?

Naquela época das aulas de saxofone, eu odiava o gravador porque ele me forçava a ouvir todos os erros horríveis que eu cometia. As retrospectivas no Scrum têm o mesmo efeito, e encarar nossos erros exige maturidade e autoconfiança.

“Precisamos estar em um ambiente de confiança,” diz Silvi. “A ideia é lavar roupa suja, então, sem confiança, muitas equipes acabam evitando as retrospectivas.”

A pressão do trabalho também é um fator. Silvi diz que as equipes sofrem muita pressão para entregar tudo no prazo, então, existe a crença de que parar para refletir vai atrapalhar o trabalho.

Ou, talvez, a equipe já experimentou fazer reuniões de retrospectiva no passado, mas sentiu falta de um processo eficiente para realmente potencializar o trabalho, então decidiu que não valia a pena.

Porém, essa mentalidade de curto prazo leva a problemas de longo prazo.

“Se você não parar para discutir sobre os desafios, pode acabar ignorando um problema sistêmico e perdendo de vista a causa que encadeou a situação,” diz Silvi.

Se você não discute os problemas que você enxerga no processo de trabalho da equipe, você vai continuar repetindo os mesmos erros. O simples ato de avaliar seu trabalho, identificar problemas e chegar a uma solução pode gerar efeitos positivos e profundos.

Silvi conta o caso de quando trabalhou com uma equipe que esperou seis meses para implementar reuniões regulares de retrospectiva no Scrum. Eles não paravam de identificar os mesmos problemas em todo Sprint:
“Não tínhamos uma parceria forte o suficiente com o time de produto. Eu trabalhava sem saber por que estava trabalhando. Só recebia ordens,” comenta um membro da equipe.

“Sem conhecimento sobre o produto, eu estava criando soluções inadequadas, trabalhava mais do que precisava e tinha retrabalho com frequência.”

Além da perda de tempo, problemas repetidos acabam com a moral da equipe. Com as reuniões de retrospectiva no Scrum, a equipe conseguiu se aproximar do time de produto, se inteirar dos objetivos do trabalho e evitar essas situações.

Como ter uma reunião de retrospectiva do Scrum eficiente?

Há inúmeros métodos para fazer uma retrospectiva no Scrum, mas você precisa conhecer alguns papéis e regras essenciais para que ela dê certo.

Funções e participantes

Facilitador: A pessoa que age na função de facilitadora dita o fluxo da reunião — redirecionando os assuntos irrelevantes, fazendo perguntas instigantes e monitorando o tempo. Tem que ser uma pessoa imparcial na reunião, dirigindo o assunto, mas sem participar.

Por mais que você ache mais seguro atribuir essa função a um gerente, Silvi acha melhor não, pois as pessoas podem hesitar em apontar erros. “O ideal é ter alguém de fora da equipe que seja imparcial.

Se não for possível, gosto de ter alguém de nível júnior ou intermediário, assim eles têm uma oportunidade para desenvolver habilidades de liderança sem a responsabilidade do poder hierárquico.”

Participantes: A retrospectiva não deveria ser uma reunião do tipo “aberta para todos”. Só quem realmente precisa estar lá deveria estar. Silvi também recomenda que líderes de nível sênior não estejam presentes para que ninguém se sinta desconfortável na hora de falar sobre erros.

Outras regras para o sucesso:

• Não usar celular ou notebook. Todos devem se concentrar na conversa.
• Não fazer anotações, exceto para definir os planos de ação como equipe para o próximo Sprint.
• Este é importante: não apontar o dedo tentando achar culpados.

Silvi gosta de começar suas retrospectivas recitando “The Prime Directive” (em português: “A Diretiva Principal”), um tipo de credo criado por Norm Kerth, consultor de software e autor:

“Não importa o que venhamos a descobrir, entendemos e realmente acreditamos que todos fizeram o melhor que podiam, considerando seu conhecimento na época, suas habilidades, os recursos disponíveis e a situação que enfrentavam”.

Silvi pede que todos na sala, um de cada vez, confirme em voz alta que concorda com essa declaração. “Ninguém quer ninguém  apontando dedos. Queremos que todo mundo acredite que estamos todos tentando melhorar.”

Ter certeza de que todo mundo na reunião pressupõe a melhor das intenções quer dizer que todo mundo tem uma abordagem positiva na conversa.

Decidindo o assunto

Um erro comum, (além de atribuir culpa) nas reuniões de retrospectiva no Scrum, é tentar fazer muita coisa. Inevitavelmente, seu time vai querer melhorar uma longa lista de processos, mas tentar consertar todos em um Sprint não é nada realista. Seu time precisa decidir em grupo qual o único item que querem tratar e como consertá-lo.

O método preferido de Silvi para alcançar essa meta é um processo chamado “mapeamento mudo”, que ele limita a 30 minutos para seguir em frente com a reunião. Cada membro da equipe pega um bloco de notas (tipo Post-It) para anotar observações sobre o Sprint, como uma carinha feliz, triste ou confusa em cada anotação. “Uma carinha feliz pode ser para algo como ‘Gostei de como colaboramos nessa tarefa,’” diz Silvi. “Uma carinha triste pode indicar algo que não deu muito certo: ‘Não chegamos a um consenso sobre a implementação’. Uma carinha confusa pode dizer: ‘Não sei por que isso não está funcionando’.”

Depois, a equipe trabalha junto para dividir as anotações em categorias. Se três Post-Its tratam da comunicação da equipe, eles ficariam juntos. Então, Silvi pede que cada membro da equipe vote na categoria que quer tratar no próximo Sprint. Ele media isso ao dar três adesivos para cada pessoa, que elas usam para “votar” na categoria que mais querem discutir.

“É importante que o time vote em uma categoria que seja possível tratar e resolver,” avisa Silvi. “Certa vez participei de uma equipe que votou em algo sobre o qual não tinham controle, e perdemos tempo conversando sobre como solucionar algo que não podíamos resolver.”

Debate

Assim que você contar os votos, já vai poder se preparar para debater o problema. A pessoa agindo como facilitador tem um papel importante nessa parte da reunião, pois os debates tendem a fugir um pouco do assunto. Silvi usa os “cinco por quês” — ouvir uma descrição de um problema e perguntar “por quê” cinco vezes — para chegar até a raiz do problema.

“Estamos perdendo tempo criando coisas que não eram necessárias.”

“Por quê?”

“Porque não sabíamos que não eram necessárias.”

“Por quê?”

“Porque não nos comunicamos com o time de produto antes de começar o trabalho.”
“Por quê?”
E assim por diante.

Depois desse exercício, Silvi usa uma técnica chamada “funil de coaching” para passar do debate do problema aos passos de ação:

• Comece com o problema: “Estamos perdendo tempo criando coisas que não eram necessárias”.

1. Converse sobre a meta: “Não crie funcionalidades que depois precisam ser deletadas no Sprint”.
2. Debata as opções para consertar o problema: “Podemos exigir mais detalhes nas requisições de funcionalidades”.
3. Debate as melhores opções.
4. Termine com um plano de ação: “Atualize o formulário de requisições de funcionalidades para incluir mais detalhes”.

Quando todos concordarem com o plano de ação, os itens podem ser registrados e implementados no próximo Sprint, ajudando o time a agir com continuidade e agilidade.

De pequenos passos a grandes melhorias

Não dá para negar. Reuniões de retrospectiva no Scrum podem dar uma intimidada, especialmente se você ainda está aprendendo o processo. Aquele gravador de fita K7 das minhas aulas de música na infância nunca se tornou a melhor parte de aprender um instrumento, mas me ajudou a melhorar mais rápido. E essa parte é divertida e recompensadora.

Lembre-se, você não está tentando resolver todos os seus problemas de uma só vez. A beleza do Scrum é a melhoria gradual. Ao consertar continuamente os itens pequenos, seu time fica mais feliz, mais produtivo e passa menos tempo lidando com dores de cabeça recorrentes.

Silvi conclui com este conselho: “Se a cada Sprint você falar sobre só um problema e consertá-lo, vai se impressionar com quão boa sua equipe vai se tornar ao longo do tempo”.

Quem deve participar da sprint Retrospective?

Quem participa da reunião de retrospectiva?

Quem participa de uma reunião de revisão do sprint?

Quem conduz a reunião de retrospectiva?