O que é uma retrospectiva de linha do tempo?
A retrospectiva de linha do tempo faz a equipe reconstruir a história de um trabalho longo, como um projeto, um trimestre ou um ano, colocando em ordem os eventos que o marcaram. A atividade vem da comunidade de retrospectivas ágeis. Esther Derby e Diana Larsen a descrevem como um exercício de coleta de dados no livro Agile Retrospectives: Making Good Teams Great, e ela se baseia no trabalho anterior de Norm Kerth sobre retrospectivas de projeto. Cada pessoa adiciona os eventos de que se lembra, coloca uma data aproximada em cada um e conta como se sentiu na época. A parte mais útil é a linha de humor. Quando você coloca os pontos altos e baixos da equipe ao lado dos eventos que os causaram, dá para ver como a energia subiu e caiu ao longo do projeto: o lançamento que animou todo mundo, a reorganização que derrubou o moral por um mês, a mudança de escopo de última hora que ninguém previu. Aparecem padrões que passariam despercebidos numa visão sprint a sprint, e quem entrou no meio do caminho consegue ouvir as partes da história que perdeu. No TeamRetro, o modelo de retrospectiva de linha do tempo tem quatro tópicos: eventos-chave, pontos altos, pontos baixos e lições para a próxima vez. Os participantes fazem o brainstorming individualmente, depois a equipe agrupa as ideias relacionadas, vota no que mais importa e encerra definindo ações com responsáveis nomeados. O formato precisa de bastante histórico para funcionar, então reserve-o para o fim de um projeto, trimestre ou ano. Para uma sprint de duas semanas não vale a pena, e um formato mais simples vai atender melhor.
Formato da retrospectiva de linha do tempo
Eventos-chave
O que aconteceu e mais ou menos quando? Um evento por ideia.
Os eventos-chave são os fatos da história: lançamentos, decisões, pessoas entrando ou saindo, incidentes, prazos e mudanças de direção. Peça que cada pessoa adicione um evento por ideia e comece cada um com uma data ou semana aproximada ("Meados de março", "Semana 6") para que a equipe possa colocá-los em ordem. Alguns dias antes da sessão, envie um lembrete pedindo que as pessoas revisem suas agendas, notas de versão, tickets e histórico de chat. A memória se apaga rápido e, sem isso, as últimas semanas acabam ofuscando as primeiras. Se os primeiros meses parecerem vazios quando as ideias forem reveladas, aponte isso e dê alguns minutos para as pessoas preencherem a lacuna.
Pontos altos
Quando a equipe se sentiu no seu melhor, e por quê?
Os pontos altos são os momentos em que a energia, a confiança ou o moral atingiram o pico. Peça que as pessoas liguem cada um a uma data ou a um evento-chave e descrevam como se sentiram, indo além do que aconteceu. "Entregar o beta foi um alívio enorme depois de semanas de dúvida" diz mais do que "Beta entregue". Procure o que os pontos altos têm em comum, como objetivos claros, boa colaboração ou progresso visível, porque essas são as condições que vale a pena recriar no próximo projeto.
Pontos baixos
Quando a equipe teve dificuldades, e por quê?
Os pontos baixos são os momentos em que a energia caiu: frustração, estresse, confusão ou esgotamento. Peça que as pessoas coloquem uma data e digam como se sentiram, e lembre o grupo de que o objetivo é entender o que aconteceu, não apontar culpados. Algumas pessoas têm dificuldade de falar dos pontos baixos na frente de um gestor, então o brainstorming anônimo no TeamRetro ajuda aqui. Na discussão, verifique se as quedas coincidem com eventos específicos. Baixas repetidas em torno de mudanças de escopo ou passagens de trabalho costumam indicar um problema de processo que merece uma ação.
Lições para a próxima vez
O que repetiríamos ou mudaríamos no próximo projeto?
As lições são o ponto em que a linha do tempo vira decisões. Peça que as pessoas olhem para os pontos altos e baixos juntos e sugiram o que continuar fazendo e o que mudar no próximo projeto. Insista em sugestões específicas: "Combinar um processo de mudança com o cliente no kickoff" é algo que dá para colocar em prática, e "Comunicar melhor" não é. Depois de agrupar as ideias e votar, transforme as duas ou três principais em ações no TeamRetro, cada uma com um responsável nomeado e um prazo, para que as lições sigam para o próximo trabalho.
Quando utilizar esta análise retrospectiva
- No fim de um projeto ou de um grande release, quando a equipe quer olhar para todo o esforço antes de seguir em frente.
- Em revisões trimestrais ou anuais, quando há eventos e altos e baixos suficientes para mostrar uma linha de humor clara.
- Quando pessoas entraram ou saíram no meio do caminho e a equipe precisa de uma visão compartilhada do que aconteceu e por quê.
- Depois de um período de trabalho longo ou difícil, para entender o que drenou a energia da equipe e o que a levantou.
- Antes de começar um projeto parecido, para reunir lições que a nova equipe possa colocar em prática. Não vale a pena fazer para uma sprint de duas semanas.
Perguntas sugeridas para quebra-gelo
- Se este projeto fosse um filme, qual seria o título?
- Qual foi um pequeno momento deste projeto que te fez rir?
Quer um exercício de aquecimento que sua equipe faça, e não apenas responda em voz alta? Veja quebra-gelos gratuitos →
Ideias e dicas para sua reunião de retrospectiva
- Envie um lembrete alguns dias antes da sessão pedindo que as pessoas revisem suas agendas, notas de versão, tickets e histórico de chat. Sem isso, o viés de recência toma conta e as últimas semanas dominam a linha do tempo.
- Peça que todos coloquem uma data ou semana aproximada no início de cada ideia. Ideias com data são muito mais fáceis de ordenar e agrupar, e deixam visível a subida e a queda do humor da equipe.
- Incentive as pessoas a dizer como cada evento foi sentido, além do que aconteceu. O lado emocional é o que diferencia uma linha do tempo de um relatório de status do projeto.
- Use o brainstorming anônimo para que as pessoas possam falar dos pontos baixos com sinceridade, principalmente quando há gestores ou stakeholders presentes. Mantenha a discussão nos eventos e nas condições, não nas pessoas.
- Reserve mais tempo do que numa retro de sprint normal. Um projeto longo tem muito histórico, então planeje 60–90 minutos e defina um tempo para cada tópico, para que as lições não fiquem espremidas no final.
- Encerre com poucas ações, cada uma com um responsável nomeado e um prazo. Revise-as no início do próximo projeto para garantir que as lições sejam aplicadas.