Eventos-chave

O que aconteceu e mais ou menos quando? Um evento por ideia.

Início de fev.: kickoff do projeto. Tínhamos um objetivo claro, mas nenhuma definição de pronto acordada.
Semana 3 - a Sarah veio do time de plataforma e assumiu o trabalho da API.
Meados de abril: o cliente pediu para trazer o módulo de relatórios para a fase um.
Pontos altos

Quando a equipe se sentiu no seu melhor, e por quê?

Lá pela semana 8, quando a primeira demo foi bem recebida pelo cliente. Finalmente senti que sabíamos o que estávamos construindo.
O hackathon de dois dias em abril. Todo mundo na mesma sala, sem reuniões, e resolvemos o problema da busca.
Sinceramente, o melhor período pra mim foi julho, quando o escopo foi travado e a gente pôde simplesmente seguir em frente.
Pontos baixos

Quando a equipe teve dificuldades, e por quê?

Meados de abril, quando anteciparam o módulo de relatórios. Tínhamos acabado de planejar as seis semanas seguintes e foi tudo para o lixo.
A migração que falhou em maio. Três noites virando até tarde e muito dedo apontado no canal.
Junho foi meio apagado. Sem designer, a gente ficava chutando a interface e refazendo trabalho.
Lições para a próxima vez

O que repetiríamos ou mudaríamos no próximo projeto?

Repetir o hackathon presencial pelo menos uma vez por projeto. Foi o que destravou a busca.
Combinar com o cliente, já no kickoff, um processo para mudanças de escopo, incluindo quem aprova e como replanejamos.
Fazer um ensaio completo de qualquer migração de dados num ambiente parecido com produção antes da semana do release.

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.

Perguntas frequentes

O que é uma retrospectiva de linha do tempo?
A retrospectiva de linha do tempo é um formato em que a equipe coloca em ordem os eventos-chave de um projeto, trimestre ou ano e depois adiciona os pontos altos e baixos que sentiu ao longo do caminho. Comparar os eventos com o humor da equipe mostra o que ajudou e o que atrapalhou, e a sessão termina com ações acordadas.
Quanto tempo dura uma retrospectiva de linha do tempo?
A maioria das retrospectivas de linha do tempo leva de 60 a 90 minutos, dependendo do tamanho da equipe e da duração do período analisado. Uma revisão de um ano inteiro com uma equipe grande pode precisar de quase duas horas.
Posso usar a retrospectiva de linha do tempo em uma sprint?
Não vale a pena para uma sprint de duas semanas. Há poucos eventos para posicionar e pouca variação de humor, então um formato mais simples, como Começar, Parar, Continuar, vai entregar mais valor em menos tempo.
Qual a diferença entre uma retrospectiva de linha do tempo e um post-mortem?
A linha do tempo cobre toda a trajetória de um projeto, o que foi bom e o que foi ruim, e observa como a equipe se sentiu à medida que os eventos aconteciam. O post-mortem investiga o que deu errado, geralmente depois de um incidente ou falha, para encontrar as causas raiz.
Como evitar que as pessoas só se lembrem das últimas semanas?
Peça que os participantes revisem agendas, notas de versão, tickets e histórico de chat antes da sessão. Durante o brainstorming, aponte os trechos da linha do tempo com poucos eventos e dê alguns minutos para as pessoas adicionarem o que aconteceu naquele período.
Por que as pessoas devem colocar data nas ideias?
As datas permitem que a equipe coloque os eventos em ordem e alinhe os pontos altos e baixos com o que estava acontecendo na época. É esse alinhamento que revela padrões, como o moral caindo depois de cada mudança de escopo.
Pronto para conduzir essa retrospectiva?Experimente esta apresentação ao vivo retrospectiva