Não faltam momentos para entregar. Faltam momentos para pensar.
Nas equipas de produto, design incluído, vamos muitas vezes de tarefa em tarefa, de release em release, sem parar para olhar para o que está a acontecer connosco enquanto equipa. Às vezes entregamos, mas nem sabemos bem como lá chegámos. Ou a que custo.
É aqui que entra a retrospectiva.
O que é, e porquê fazer?
Uma retrospectiva não é uma moda, nem uma “reunião de Agile”. É um momento intencional para a equipa parar e perceber o que funcionou, o que não correu tão bem e o que pode ser feito de forma diferente.
É útil porque:
- Dá visibilidade ao que normalmente se ignora: comunicação, alinhamento, decisões apressadas, silêncios que pesam. Aqui, práticas como dysfunction mapping podem ajudar a tornar esses padrões mais visíveis.
- Permite ajustar a forma como trabalhamos, e não só o que entregamos.
- Humaniza o processo. Faz-nos lembrar que somos pessoas, não funções.
“Mas isso não é coisa dos developers?”
Esta pergunta aparece muitas vezes. A resposta é simples: não. Retrospectivas são para equipas. E equipas existem em várias formas. Algumas são multidisciplinares e trabalham juntas do início ao fim de um produto. Outras estão organizadas por disciplina, como design, produto, research ou engenharia. E em ambos os casos, faz sentido parar para refletir sobre a forma como o trabalho acontece. Independentemente da estrutura, todos contribuímos para o resultado final. Refletir sobre como colaboramos, comunicamos e decidimos, enquanto grupo, ajuda-nos a identificar o que está a funcionar e o que pode ser ajustado. A retrospectiva não é para “resolver problemas”. É para observar, escutar e evoluir. Seja numa equipa de produto completa ou num departamento funcional, este hábito fortalece a consciência coletiva e leva a entregas mais sólidas, com menos fricção.
Como fazer, na prática?
Mantém simples.
- Escolhe o momento certo. Pode ser no fim de um sprint, no fim de um projeto ou sempre que sentires que a equipa precisa de parar. Mas torna-o recorrente e consistente.
- Cria um ambiente seguro. Um espaço onde todos sintam que podem falar. Aqui não se trata de culpas, mas de perceber o que está a acontecer.
- Faz perguntas com intenção:
- O que correu bem e queremos manter?
- Onde perdemos tempo ou foco?
- Houve falhas na comunicação?
- O processo ajudou ou atrapalhou?
- Dá-lhe uma temática com a qual a equipa se relacione. Isto faz toda a diferença na energia e na abertura que a retrospectiva vai ter. Pode ser algo que aconteceu com a equipa, uma referência cultural ou até um momento divertido. Já usei como ponto de partida o facto de alguém ter achado que segunda-feira era feriado, e não era. Ou aquela vez em que um dos membros não conseguia falar na call e acabámos a brincar com os “fones da Temu”. Numa outra, a equipa organizou a retrospetiva em torno de uma pergunta: o que é que o Scrum Master devia saber quando voltar de férias?, e deixaram-lhe mensagens diretamente.
Estes detalhes criam ligação, facilitam a partilha e tornam a retrospetiva menos “mais uma reunião” e mais um momento genuíno da equipa. - Sai com pelo menos uma ação clara. Não vale a pena fazer uma retrospectiva só para desabafar. Tem de haver consequência, por pequena que seja.
- Torna essa ação visível e atribui-lhe um responsável. Regista-a num espaço acessível à equipa: um board, um documento ou uma nota na parede virtual. E define quem a vai acompanhar. Sem ownership, as ações perdem força. Com visibilidade e responsabilidade, tornam-se compromisso.
Exemplos típicos do que pode surgir
- O design foi feito em cima do joelho porque o briefing chegou tarde.
- Estivemos demasiado tempo a discutir detalhe e perdemos a visão geral.
- Ter envolvido a dev team logo na fase de protótipos evitou retrabalho.
- As validações com utilizadores ajudaram a priorizar melhor. Devíamos repetir isso.
Estas conversas são resultado de pararmos para pensar juntos. E têm impacto direto na forma como a equipa trabalha e entrega.
Isto não é sobre reuniões, é sobre maturidade
Retrospectivas não são um ritual para “parecer ágil”. São um hábito de equipas que levam o seu trabalho a sério. Que não querem só entregar: querem entregar melhor, com menos atrito, com mais alinhamento e com mais clareza.
Se nunca paraste com a tua equipa para pensar no processo… experimenta. Não precisas de uma metodologia. Só precisas de vontade de melhorar. E de estar disponível para escutar, mesmo o que não é fácil de ouvir.
