Retrospectiva é sobre FUTURO

Registro de um bate-papo em Recife

Desde que entrei no time da Concrete aqui em Recife, temos nos reunido periodicamente para falar durante 10 minutos sobre algo relacionado à agilidade. A ideia da conversa, mais rápida que uma Daily, é trocar conhecimento e relembrar algumas dicas importantes sobre o tema. O cardápio e o tema mudam a cada reunião, mas o importante é que todo mundo aprende junto.

A cada encontro, vou tentar escrever aqui no Blog um resumo do que foi falado. Assim, a gente compartilha também com você, nosso leitor, o que aprendemos. Hoje vou escrever sobre a Retrospectiva do Scrum! Ou, para os íntimos, Retro ou Retrô. Bora lá?

Primeiro, e mais importante, é que a Retrospectiva fala mais sobre o futuro, ou seja, como podemos ser melhores na próxima iteração, do que sobre o passado, o que aconteceu e porque aconteceu. Por isso, se o espírito do time neste momento for o de “lavar a roupa suja”, o motivo da cerimônia — o KAIZEN — estará perdido.

Logo, temos: IF team.vibe = “lavar a roupa” then Kaizen = null;

O foco da Retrô deve ser sempre o de “como podemos funcionar melhor”, no plural. Não interessa o desempenho individual, é o desempenho do time na Sprint que está terminando que deve ganhar relevância e pontos de melhoria, vide os resultados obtidos e como se trabalhou em equipe.

Falando dessa moça, a Retrospectiva do Scrum é o último dos cinco eventos de cada Sprint. Mas o que é Sprint? Uma iteração com tempo fixo, de uma a quatro semanas de duração, com o objetivo de entregar um incremento de software funcionando, alguma coisa “pronta”, seja de qualquer projeto de qualquer área (TI, RH, contabilidade, marketing, engenharia, etc).

A Sprint sempre começa com uma Planning no primeiro dia, pela manhã, de preferência, na qual se define a meta da Sprint. Do segundo ao penúltimo dia, temos uma Daily de 15 min, no máximo, sempre no mesmo horário, com o DEV Team revisando o caminho para a meta. No último dia da Sprint são duas as cerimônias: a Review, para a qual a palavra-chave é feedback, e a Retrospectiva, para a qual a palavra-chave é Kaizen, ou melhoria contínua.

A Retro tem timebox de até três horas para sprints de quatro semanas e proporcional para as menores (1h30m, se duas semanas; 45min, se uma semana, por exemplo). Participam dela o Scrum Team, formado pelo Scrum Master, Product Owner e Dev Team, e mais ninguém. É uma oportunidade de inspeção e adaptação, dois dos três pilares do Scrum, e os valores de respeito e abertura falam bem alto nesse evento, pois sinalizam o quão importante é a empatia entre as pessoas e suas diferentes opiniões, bagagem profissional e hábitos, além da liberdade/intimidade suficientes para levantar os problemas, sempre buscando as soluções. A Retro é a grande oportunidade para o time se avaliar quanto a pessoas, relacionamentos, processos e ferramentas.

Por fim, é nesse evento que revisamos a “definição de pronto”, que basicamente é uma checklist que diz se o incremento pode ser usado pelo cliente ou não, ajustando-a com os feedbacks recebidos na Review + os do time, na autonomia de dar mais qualidade à sua próxima entrega. Isso pode ser feito de várias formas, mas o núcleo é sempre o de avaliar o que foi bom, o que poderia ter sido melhor e o que pode melhorar.

Conceito dado, e com o tempo de amizade com essa moça, gostaria de descer um pouco mais e colocar uma lupa sobre alguns aspectos da Retrô:

a) A Retrô não é um muro de lamentações: ficar resmungando e chorando sobre o que deu errado, sobre as panes de relacionamento ou de sincronia entre tarefas ou de uma ferramenta que não funcionou bem… Isso não vai adiantar. Já passou, já aconteceu, e a única coisa a ser feita é pensar em como mitigar ou eliminar o risco de repetição, pensando em uma solução que envolva o que precisa, seja uma ferramenta, uma etapa de processo, ou ambos;

b) A Retrô também não é um tribunal de Júri, no qual as pessoas apontam os culpados e ele se defende ou usa advogados para tal. Entendendo que “já passou, já aconteceu”, não vale a pena relembrar erros individuais, cobrar posturas, pedidos de desculpas, etc. Isso quebra mais a unidade de um time do que ajuda na solução. Novamente, a vontade de todos deve ser a de RESOLVER, seja uma pessoa-backup pra fazer um determinado processo, um alinhamento entre todos sobre um comportamento inadequado (para todos) ou um ajuste de ferramenta para algo que funcione melhor para o time todo.

c) A Retrô é uma maravilhosa oportunidade de ouvir e falar, como TIME, como NÓS! “Nós estamos tendo muitas reuniões e isso está atrapalhando o flow. O que faremos para melhorar isso? Podemos colocar a Daily para um horário pré-intervalo? Podemos sequenciar a Refinement Session pós-Daily, para evitar outras interrupções?” Sendo didático com alguns exemplos, e sem “mimimi”.

d) A pergunta chave de todo o tempo deve ser: como podemos melhorar isso? Sempre NÓS, sempre o TIME. A falha, qualquer que seja, foi do time, até porque se aconteceu algo individual, medidas prévias poderiam ter sido tomadas, ou melhoramos a auto-organização para resolver rapidamente e sem grandes impactos. Não é isso?

Por fim, algumas sugestões que podem refletir em suas retrospectivas, veja se faz sentido pra vocês. Se sim, o próprio time, auto-organizado, pode se regular e passar a usar. Afinal, esse é o Kaizen: melhoria contínua, em pequenos ajustes, buscando evoluir a cada iteração.

1. Pelo menos um dos itens do plano de ação da Retrospectiva deve entrar na Sprint seguinte. Sem isso, não há Kaizen! Se gerar plano de ação e nada entrar na iteração seguinte, a sensação de perda de tempo e de “problemas continuam” já derrubará o ânimo para o novo ciclo que começa já no próximo dia. Quer coisa melhor que achar a solução de um problema e já vê-la endereçada no dia seguinte? O Product Owner (dono do backlog), e o Dev Team (dono da meta da sprint ou Sprint Backlog) estão presentes e podem garantir isso.

2. Desarme o coração. “Deixa chegar a Retrô que eu vou botar pra quebrar!”. Isso não só não vai ajudar, como vai atrapalhar — e muito. Entendam que já passou, que já aconteceu, que não há nada a fazer quanto a isso, e que propor uma solução é mais inteligente, mais objetivo e mais sadio para o time.

3. Seja objetivo. Se durante a Sprint você achou um problema, “postita” no seu monitor, já usando o NÓS e o TIME, e comunica ao Scrum Master. Quanto antes resolver, melhor. Se chegar na Retrô ainda com ele, você já sabe como abordar. E não se esqueça de perguntar: como podemos melhorar isso?

4. Timebox é um limite de tempo. Citando Lisette Sutherland, em “Work Together Anywhere”, o trabalho remoto é um jeito diferente de trabalhar. Logo, alguns ajustes podem ser necessários. Você consegue passar 1h30m em uma conferência remota, atento a todas as pessoas, opiniões e discussões? Pois é… Creio que, para times remotos, é imprescindível enxugar esses tempos ao máximo, mantendo o foco das pessoas e a construção das soluções, sem conversas paralelas, ruídos desnecessários, chats de WhatsApp. Faça isso sendo objetivo, pontuando e chegando a um consenso rápido para aquele momento e informações disponíveis. A solução ideal pode não chegar “de primeira”, e não há problema nenhum nisso.

Por fim, as boas práticas do Scrum são #GOOD4ALL, ajudam times ágeis na auto-organização e no ótimo ambiente de trabalho, independente se este ou aquele não quiser ou precisar do rótulo SCRUM. Criem um ponto de inspeção e kaizen a cada entrega feita, para se reavaliarem quanto a pessoas, processos, relacionamentos e ferramentas, gerando evolução e melhoria — oxigênio para vocês — e, melhor ainda, para os resultados do negócio. Seja ágil!

Ficou alguma dúvida ou tem algo a dizer? Aproveite e deixe um comentário. Quer participar dessas reuniões periódicas sobre agilidade? Saiba mais sobre a Concrete aqui e deixe o seu currículo. Quem sabe o próximo tema a ser debatido não é você quem escolhe? ;) Até a próxima!