Reuniões Retrospectivas

Engenharia de Software | Gerenciamento de Projetos de Software | Reuniões Retrospectivas

Reunião de retrospectiva

A reunião de retrospectiva é um recurso de melhoria contínua, uma ferramenta de comunicação e de evolução do time. Times imaturos costumam dar menos valor para este evento, porém a prática de retrospectiva vem sendo utilizada em diversos ambientes de equipes e projetos (mesmo em ambientes não ágeis), pois permite intensificar as características fortes de cada time e eliminar pontos de fraqueza.

Uma vez que a revisão está concluída, o time (sem as partes interessadas, a não ser que o Time de Desenvolvimento e o Scrum Master decidam convidar…) realiza uma retrospectiva para determinar o que seus membros fizeram bem e o que querem continuar fazendo, o que foi ruim no Sprint, e quais as recomendações de melhoria daqui para frente. Um plano de ação é criado e esses itens são implementados ao longo do próximo Sprint, e revisado para a eficácia na retrospectiva do Sprint seguinte. Geralmente a reunião de retrospectiva não deve ocupar mais de 3,75% do Sprint (por exemplo, em um Sprint de 2 semanas não deve durar mais de 3 horas).

Etapas das reuniões de retrospectiva

Existem diversas técnicas de retrospectiva, porém todas elas possuem as seguintes etapas:

• Identificar o problema.
• Identificar causas raízes.
• Identificar soluções.
• Propor soluções para diminuir ou eliminar o problema (em sua causa raiz).
• Testar a solução.
• Incorporar a solução no processo e no time.

Independente do método/framework ágil que for utilizado, existem elementos comuns que quando bem utilizados agregam valor ao projeto.

Vamos apresentar algumas dinâmicas que podem ser utilizadas nas reuniões de retrospectiva. Avance a tela.

Dinâmica bons e ruins

Esta dinâmica é muito interessante em retrospectivas de equipes com alguma experiência em agilidade ou para times que já se conhecem há algum tempo:

• Permite a exposição dos problemas relevantes no momento em que o time se encontra;
• Permite que o time apresente, entenda e proponha soluções para os problemas (autogerenciamento);
• Integra o time;
• Gestão do conhecimento do time.

Dica: Nunca é tarde para lembrar ao time que a retrospectiva não é um caça às bruxas e sim uma ferramenta de melhoria, logo, não é o momento de acusações, mas de soluções. O time deve ter maturidade e não levar nada para o lado pessoal e o facilitador deve lembrar o time esses pontos sempre que necessário!

1. Cada membro do time recebe post-it e canetas (de preferência todos da mesma cor) e escreve os pontos bons e ruins do Sprint.
2. Quando todos finalizarem, colam-se os post-its em um lugar visível (veja um exemplo de quadro).
3. É feita a leitura dos tópicos ruins, observe que os problemas mais sérios terão mais post-its.
4. O time discute os problemas e propõe ações de solução.
5. Faz-se a leitura dos pontos bons (práticas que devem ser mantidas)!

Obs.: Dependendo do número de problemas é interessante concentrar esforços para resolver 2 ou 3 mais sérios.

Considerações:

Problemas que não geram ações e soluções podem ser adiados para discussão posterior, esses problemas devem ficar na área de parking lot do quadro.

Ações devem ser atitudes concretas que permitam a execução sem dupla interpretação. Por exemplo: ”Quem desenvolveu deve realizar testes unitários!”. Uma sugestão é as ações serem endereçadas, por exemplo, fulano de tal é o responsável por lembrar da importância da ação XYZ durante o próximo sprint.

Ao final da retrospectiva, deve-se jogar no lixo os post its e deixar fixadas as ações combinadas visíveis para todos, elas podem ficar no quadro kanban para que todos se lembrem!

Dinâmica mercado de habilidades (Market of skills)

Essa dinâmica é muito interessante em retrospectivas de equipes que estão no processo de transformação para times! Alguns benefícios são:

• Acelera o autoconhecimento como time;
• Permite que o time inicie seu autogerenciamento, onde cada um assume como e quando ajudar;
• Integra o time;
• Gestão do conhecimento do time.

1. Liste as habilidades que você tem e julgue ser útil para o time e para o produto.
2. O que você tem vontade de aprender? Como isso será útil para o time? Como isso será útil para o produto?
3. Informações adicionais. Apresente o que você tiver vontade para o time (extra time, extra produto) que você sinta vontade de compartilhar.
4. Venda-se para o time!
5. Defina ações!

Dica: Nesta etapa, os membros do time identificam interesses comuns, o que facilita o processo de comunicação e aproximação.

Dica: Durante a venda, todos podem acrescentar habilidades esquecidas pelo vendedor (passo 1), formas de ajudar nas vontades (passo 2).

Após a primeira aplicação dessa dinâmica, o time deve repeti-la (mais adiante no projeto) e verificar sua evolução.

Exemplo: na primeira dinâmica, o time tinha identificado o seguinte quadro de conhecimento:

Após ações como programação pareada, a tendência é que o time compartilhe conhecimento e melhore suas habilidades. A próxima dinâmica poderia gerar um resultado melhor, como o ilustrado abaixo:

Técnica PrOpER

A abordagem mais simples é escolher uma coisa e pular dentro. Se não é óbvio qual é o problema para trabalhar em primeiro lugar, então você pode ter uma abordagem ágil. Faça uma tempestade de ideias, gere uma lista de áreas problemáticas para trabalhar no que poderia melhorar a vida da sua equipe no projeto. Então priorize essa lista com base em sua missão de treinamento – agora você tem um ponto de partida!

Você pode aplicar o ciclo PrOpER adequando a cada episódio de coaching ou na retrospectiva.

ATENÇÃO

• Problema: escolha o problema para trabalhar. Veja como a equipe trabalha. O que precisa ser melhorado?
• Opções: considere as suas opções. O que você poderia tentar que poderá influenciar a situação para melhor? Relacione pelo menos três opções.
• Experimente: escolha uma opção e a execute.
• Revisão: analise o resultado. Você melhorou as coisas? Mesmo que as coisas não melhoraram, você aprendeu alguma coisa?

Vamos praticar o PrOpER através de um exemplo.

Problema: Roberto chegou tarde para a reunião de Daily Scrum hoje. Aconteceu na semana passada também. Você está preocupado, porque ele está trabalhando na construção de um ambiente de teste novo. Ele está perdendo informações importantes sobre os problemas da equipe com o ambiente de teste atual.

Opções: Aqui estão algumas opções que você pode considerar:

• Pegue o touro pelos chifres: quando Roberto chegar, peça um tempo para informá-lo sobre o que ele perdeu até o momento no Daily Scrum. Enquanto você está revendo os pontos, fale com ele sobre a importância de participar do Daily Scrum todo dia.
• Educar a equipe: executar uma sessão de treinamento para toda a equipe para aprender a melhorar o Daily Scrum, o que pode ajudar Roberto a entender porque é importante para todos na equipe a participação na reunião.
• Deixe-os segurando o bebê: Você precisa de alguém para cobri-lo: pergunte se Roberto pode ajudá-lo, executando amanhã o Daily Scrum.
• Espere e veja: não faça nada e espere para ver se a equipe fará com que Roberto perceba que o seu atraso é um problema por si só.
• Experimente: você escolhe a opção para primeiro falar com Roberto sobre isso. Inicie a conversa, mencionando que você percebeu que ele perdeu o Daily Scrum algumas vezes. Ele parece genuinamente surpreso que isso era importante, já que a partir de sua perspectiva, seu trabalho não está diretamente ligado a nenhum cliente, por isso ele não precisaria estar lá. Explique sua preocupação em ele perder informações de seus companheiros de equipe que precisarão ser consideradas na construção do ambiente de teste novo. Também explique que o Daily Scrum é para a equipe, e não para o cliente.

Sugira que ele convoque uma reunião com o testador (e time) para verificar as questões que provavelmente não foram atendidas. Ele concorda em chegar no horário no próximo Daily Scrum.

• Revisão: Revisão do resultado. No dia seguinte, Roberto chegou no horário acordado? A sua conversa fez a diferença? Se ainda há problemas, então, que outras opções você pode tentar?

ATENÇÃO

Ao tentar chegar às opções, algumas ideias podem ser consideradas:

• Trazer o problema à tona: torne o problema visível para a equipe.
• Socializar o problema: converse com a equipe sobre o problema.
• Espere e veja: deixe este problema: se piorar, a equipe provavelmente notará.
• Tire o corpo fora: transfira o problema para outra pessoa dentro ou fora da equipe.
• Análise de causa raiz: procure a causa raiz do problema.
• Educar a equipe: forneça à equipe mais informações para que eles vejam uma solução.
• Coloque-os no comando: entregue a responsabilidade para a equipe ou a um membro da equipe.

Referencias

SCRUM GUIDE. Disponível em: <http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf>. Acesso em: 20 jan. 2015.

Engenharia de Software | Gerenciamento de Projetos de Software | Reuniões Retrospectivas