1.Introdução

Retrospectivas são empregadas para analisar o que aconteceu com as equipes e estudar possíveis melhorias. Muitas vezes é criada uma linha do tempo (timeline) para registrar a evolução da equipe. Em Lean Manufacturing essa prática é conhecida como Kaizen, que significa melhoria contínua.

 

Retrospectiva, segundo o Aurélio é: s.f. O mesmo que retrospecto,
enquanto retrospecto é definido da seguinte forma: s.m. Vista ou análise de fato passado.

 Segundo a Wikipedia, a palavra retrospectiva vem do latim retrospectare, que significa "olhar para trás". Ou seja, retrospectivas são nada mais, nada menos, que encontros nos quais o objetivo é olhar os fatos decorridos e tentar encontrar pontos que podem ser melhorados e estudar como aplicar tais melhorias, visando aumentar os ganhos e diminuir os desperdícios.

Henrik Kniberg diz em seu livro Scrum and XP from the Trenches: "Sem retrospectivas você percebe que a equipe continua cometendo os mesmos erros de sempre". Retrospectivas tratam do processo que a equipe utiliza, são uma maneira de identificar onde as coisas não estão saindo como o esperado e estudar como diminuir os problemas. 

Muitas equipes que tentam fazer retrospectivas acabam desistindo de fazê-las, pois alegam que não perceberam resultados. O problema pode estar no fato de que quem fez a retrospectiva não sabia como fazê-la. Por vezes, justificar para a equipe que restrospectivas são fundamentais não é tão simples, muitas pessoas só reconhecem o valor dessa prática quando experimentam seu funcionamento.

Segundo Rachel Davies e Liz Sedley, no livro Agile Coaching, as retrospectivas devem ser a primeira prática a ser usada pelas equipes que estão começando a usar métodos ágeis. O motivo é que nas retrospectivas são discutidos vários problemas e durante a próxima iteração a equipe já pode introduzir as mudanças e ver melhorias. 

2.O Papel do Facilitador

Toda retrospectiva precisa de alguém para facilitar o encontro. Alguém que guie a retrospectiva, que consiga extrair os problemas, idéias e soluções da equipe. Tal pessoa é o facilitador da retrospectiva.

2.1 Facilitando uma Retrospectiva

Cada vez que uma iteração termina deve ser feita uma retrospectiva para abordar os seguintes tópicos:

• Quais idéias a equipe teve desde a última iteração?
• Quais áreas a equipe quer focar em melhorar?
• Em quais idéias eles podem trabalhar na próxima iteração?

Metade do tempo da retrospectiva deve ser gasto analisando a iteração passada, identificando o que aconteceu e os "porquês". Em seguida, idéias são levantadas para que possam ser criados planos de ação (action plans), que dizem o que deve ser feito para implantar melhorias. Os próximos passos são integrar à próxima iteração as ações mais prioritárias.Para que uma retrospectiva seja proveitosa, é necessário tempo e prática, não adianta tentar consertar muitos problemas numa única iteração - na maioria das vezes não vai funcionar.

3. A Retrospectiva Feita nos Dojos

É um costume em coding dojos fazer uma retrospectiva no fim. Sempre que chega no tempo combinado da duração do dojo, é feito uma retrospectiva. A maneira mais básica de fazer a retrospectiva é dividir o quadro (ou flip chart) em duas colunas: O Que Foi Bom, O Que Foi Ruim. Opcionalmente, uma divisão entre as duas colunas é empregada para listar informações sobre o que pode ser melhorado.Um exemplo de retrospectiva de um dojo com duas colunas pode ser visto na Figura 1:

Figura 1: Exemplo de Retrospectiva de Dojo 

Muitas vezes as restropectivas em dojo não surtem efeito , por não ser possível criar um plano de ações para melhorar o processo. A retrospectiva acaba ficando mais como lição e compartilhamento de visões, sem gerar, de fato, ações de melhorias.

4. Como Olhar Para O Passado

Há algumas maneiras de recolher informações do passado. O objetivo nesse momento da retrospectiva é entender o que aconteceu e os membros da equipe precisam compartilhar suas histórias individuais e integrá-las com as dos outros membros. Algumas maneiras de alcançar tal objetivo são:

Linha de tempo colorida: É criada uma linha de tempo no quadro ou em algum lugar onde possa ser colado post-its e escrever os acontecimentos na linha de tempo. Post-its coloridos com frases descritivas são usados para indicar os sentimentos da equipe em determinado lugar na linha de tempo. Normalmente é usada a cor verde para o que foi proveitoso, rosa ou vermelho para o que foi estressante e amarelo para o que for neutro. Talvez seja necessário colocar uma legenda para as cores ao lado da linha de tempo para que ninguém se perca. 

Galeria de arte (art gallery): O facilitador pede a equipe que cada um desenhe uma imagem do que o projeto se parece para eles, depois cola as imagens em algum lugar visível a todos. Assim que todos terminarem o facilitador pede que cada explique o seu desenho. Pode parecer estranho, mas as pessoas são muito boas em encontrar metáforas para o que é difícil de ser explicado com palavras. Um relato interessante citado no livro Agile Coaching foi de uma retrospectiva em que um membro desenhou um boneco de palitinhos dentro de uma caixa, e quando foi explicar para a equipe o desenho ele disse que era assim que ele se sentia no projeto - ele trabalhou muito isolado dos outros, e era como se ele não fizesse mais parte do projeto.

Uma variação interessante de art gallery que Patrick Kua desenvolveu é denominada Mr. Squiggle. Esta variação funciona da seguinte maneira: o facilitador desenha alguns traços em papéis (podem ser usados post-its) e entrega um papel para cada membro da equipe, contendo os mesmos traços criados pelo facilitador. A equipe tem 5 minutos para desenhar nos papéis o que o projeto representa para cada um, usando os rabiscos que o facilitador colocou no papel. Depois é pedido que cada um explique seu desenho para a equipe. O interessante do Mr. Squiggle é que cada um faz um desenho totalmente diferente, mesmo iniciando com os mesmos traços.

5. Bad Smells

"If it stinks, change it"
    Avó de Kent Beck, discutindo sobre como criar os filhos

Assim como com código, é possível ver Bad Smells em retrospectivas - aqueles indícios de que há algo errado:

Idéias da última iteração são ignoradas É pedido a equipe novas idéias sem discutir o que aconteceu na última iteração. Isso não funciona, pois os problemas são evitados.

Palavras ao vento Vários itens estão nas colunas "O que foi bom" e "O que não foi bom", mas nenhuma ação é tomada em relação às informações recolhidas.

Mudar o mundo Algumas equipes criam listas com coisas a serem melhoradas sem considerar a viabilidade de fazer aquelas ações na próxima iteração. Isso traz desapontamento à equipe, porque não conseguiram fazer o que planejaram, e a cada retrospectiva são adicionadas mais ações.

Ações sem "Donos" Ações que foram criadas e não possuem donos, algo como "Melhorar a comunicação" e "Fazer mais refactoring", não deveriam ser ações, pois são problemas que devem ser trabalhados. Se não houver discussão, a equipe não vai saber como implementar tais "pseudoações".

Falta de tempo para melhorar A equipe leva cinco minutos depois de uma apresentação de uma release ou demo para conversar brevemente sobre os acontecimentos e chama isso de retrospectiva. Esse é um sinal de que a equipe não vê benefícios em retrospectivas.

6.Peneirando Informações

Depois que foram recolhidas informações suficientes é necessário gerar insights. Caso haja alguma informação que ainda não foi compreendida, a equipe deve esclarecê-la - não deve ser pedido diretamente para a pessoa que escreveu a nota que explique, mas sim à equipe que o faça. A presença de frases genéricas como "Ambiente de testes quebrado" ou "Cliente muito ocupado", devem ser solicitados exemplos para tornar mais fácil ilustrar o problema para todos.

Depois de andar sobre a timeline procurando por insights é a hora de escolher os tópicos mais importantes para focar. Uma das técnicas é votação por pontos (dot voting). Cada membro da equipe tem três pontos que pode colocar em qualquer tópico que ache que é mais prioritário - inclusive pode usar os três pontos em um tópico só. Os tópicos com maior pontuação farão parte do planejamento de ações (action planning). Após extrair os tópicos que a equipe quer focar, procura-se por melhorias no processo que a equipe possa fazer na próxima iteração.

7.Olhando para o Futuro

A segunda metade da retrospectiva deve olhar para a próxima iteração, que é quando a equipe vai trabalhar o que gostaria de mudar no processo. Será necessário mais que concordar que determinadas mudanças são necessárias, a equipe deve trabalhar nas ações levantadas para implantar estas mudanças.

Antes de começar a criar ações novas, tempo deve ser dedicado para revisar o que aconteceu com as ações da última retrospectiva. Se não foram terminadas a equipe precisa entender o motivo antes de adicionar mais ações. Na maioria dos casos é porque as ações não tinham dono ou porque a equipe "não teve tempo".

Um tempo deve ser investido na retrospectiva para trabalhar num plano de ações realista e que seja claro para todos da equipe. O facilitador combina com a equipe quanto tempo será gasto com as melhorias no processo na próxima interação, lembrando que as ações serão feitas enquanto a equipe continua trabalhando no plano do release, ou seja, enquanto continuam a desenvolver software.

8. Como Criar o Plano de Ações

Assim como no desenvolvimento de software, a equipe deve dar passos de bebê (baby steps) na hora de criar as ações para serem implementadas na próxima iteração. Nem sempre as ações são problemas que podem ser corrigidos - às vezes são estudos sobre algum problema, estabilizar um estilo de código etc. Uma boa referência de como criar planos de ação é fornecida por Bas Vodde.

Para ter ações que funcionam, a equipe precisa, além de identificar o que precisa ser alterado, dizer como serão implementadas as mudanças. O processo de recolher as ações que Bas Vodde emprega se baseia no princípio de que cada ação tem um objetivo a longo prazo e uma ação para ser feita imediatamente, como por exemplo:

Objetivo a longo prazo: Ter testes de aceitação automatizados
Ação para agora: Fulano vai automatizar o teste ABC usando XYZ.

No exemplo citado por Bas Vodde a equipe consiste de oito membros. Inicialmente cada membro gera um conjunto de ações - separadamente - cada uma com um objetivo a longo prazo e uma ação para ser feita; a equipe tem 10 minutos para gerar as ações. Após geradas as ações, a equipe se divide em duplas. Durante 10 minutos cada dupla agrupa suas ações e seleciona as 5 mais prioritárias. Depois que as duplas selecionarem 5 ações, são gerados grupos de 4 pessoas. Cada grupo agrupa suas ações e seleciona apenas 4 de todas as 10 ações selecionadas (2 duplas selecionaram 5 ações cada) - durante o limite de 10 minutos. Para finalizar, a equipe inteira reúne-se e de todas as 8 ações selecionadas (2 grupos de 4 pessoas e cada grupo selecionou 4 ações), seleciona as 3 mais importantes para serem implementadas na próxima iteração.

A vantagem dessa técnica é que ela reúne tanto esforço individual quanto em grupo, além de ter que haver um consenso entre todos os membros da equipe sobre quais são as prioridades. Devagar e com passos de bebê. Independente do número de ações geradas inicialmente, no fim, apenas três ações são selecionadas. Selecionar ações demais é um erro, que já foi descrito anteriormente como bad smell (Mudar o Mundo).

Depois da retrospectiva as ações precisam ser planejadas na próxima iteração. A equipe combina como serão priorizadas as ações e post-its com as ações podem ser grudados no quadro, para que não sejam esquecidos durante a próxima iteração.

9. Um Formato para Começar

Há vários formatos de retrospectivas, alguns mais complicados que outros. Anteriormente foi descrito um formato, mas não é recomendável que seja usado da primeira vez. Antes da retrospectiva começar é necessário definir um local e material como canetas, papel, post-its e um quadro.

Um exemplo de como dividir a retrospectiva, citado no livro Agile Coaching segue:

• Revise o objetivo do encontro, e relembre a equipe das regras básicas (5 minutos)
• Crie uma linha de tempo (15 minutos)
• Pegue insights baseado na linha de tempo (15 minutos)
• Selecione tópicos para focar (10 minutos)
• Revise o progresso de ações prévias (5 minutos)
• Gere idéias para melhorias (15 minutos)
• Faça um planejamento de ações (15 minutos)

Esse formato é recomendável para quem quer iniciar retrospectivas, mas usar o mesmo formato sempre não é interessante, pois se torna chato, tanto para equipe quanto pro facilitador. Então, varie os formatos. Há vários formatos listados na wiki Agile Retrospective e podem ser encontrados em http://agileretrospectivewiki.org/index.php?title=Retrospective_Plans.

10. Diretriz Primária (Prime Directive)

Tratando-se de retrospectivas há algumas regras básicas, como em qualquer outra reunião, como: não usar computadores, colocar os telefones no silencioso, esperar a vez para falar. Além das regras básicas há uma diretriz que é chamada de prime directive, que diz: "Independente do que nós descobrirmos, entendemos e acreditamos que todos fizeram o melhor que podiam, dado o que sabiam na época, seus conhecimentos e habilidades, os recursos disponíveis, e a situação em questão".

É claro que o mundo não é perfeito e as pessoas cometem erros. Apesar da diretriz primária parecer dizer que problemas não serão causados por indivídios, é bom deixar claro que as retrospectivas não são o melhor lugar para discutir problemas de perfomance dos membros. Retrospectivas devem focar em como melhorar o processo; caso a performance de algum indíviduo venha à tona, mude o foco de volta para as ações da equipe.

Rachel Davies e Liz Sedley recomendam que na primeira vez que for feita uma retrospectiva, seja colado na parede a prime directive e que você explique para a equipe o que ela significa.

11. Checklist

Resumidamente:

• Comece a retrospectiva olhando para o passado para entender o que aconteceu o o porquê. Dê tempo suficiente à equipe para contar a história inteira

• Use a segunda metade da retrospectiva olhando para o futuro e decidindo o que irá no plano de ações

• Procure por bad smells que estão atrapalhando a equipe a ser mais efetiva. Se as retrospectivas não estão melhorando o processo, pense em como você poderia melhorá-las

• Ache os problemas que a equipe mais quer consertar. Use a votação por pontos para focar no que a equipe gastará suas energias

• Não adicione mais ações durante a iteração antes da próxima retrospectiva. Até mesmo duas ou três ações terminadas a cada iteração podem causar um impacto significante por vários meses

• Se as ações da última retrospectiva não foram finalizadas, procure saber os motivos antes de adicionar mais

Referências

O livro Agile Coaching é excelente, a maior parte do conteúdo do post é baseado no capítulo 13 dele. Há um livro só sobre retrospectivas, Agile Retrospectives. Há outro livro também só sobre retrospectivas, Project Retrospectives, no qual os autores têm um site com material muito bom sobre retrospectivas.

 

<< Quadro de Tarefas

Reuniões Diárias (Standup Meetings/Daily Standups) >>