Como conduzir Retrospectivas de Sprint que funcionam?

Atualizado em 17/04/21!

O Scrum é um framework ágil de gerenciamento de projetos que envolvem produtos complexos, geralmente usado em equipes de software, embora existam diversas adaptações para outros tipos de times.

Costuma-se dizer que o Scrum é simples de entender, mas difícil de aplicar e embora esse paradoxo soe confuso, é exatamente isso. Em partes isso se deve à total necessidade de se aplicar seus três pilares: transparência, inspeção e adaptação, e em partes devido à sua simplicidade de definir poucas reuniões e poucos artefatos, muitas vezes lhe deixando sem ideias de como facilitar (enquanto Scrum Master) reuniões como a Retrospectiva da Sprint (Sprint Retrospective).

Neste post quero dar uma boa ideia nesse sentido, de como conduzir uma Retrospectiva de Sprint que realmente funcione segundo os pilares do Scrum.

Veremos:

1. O que é uma Retrospectiva de Sprint?
2. Como facilitar uma Retrospectiva?
3. Ações concretas

Depois de ler e se quiser saber mais sobre o meu trabalho com Scrum, dê uma olhada no livro que escrevi.

#1 – O que é uma Retrospectiva de Sprint?

A Retrospectiva da Sprint, segundo o próprio Scrum Guide 2020, é:

O propósito da Sprint Retrospective é planejar maneiras de aumentar a qualidade e a eficácia.

Ou seja, de todas time-boxes do Scrum, certamente a Sprint Retrospective é a mais alinhada com os pilares da Inspeção e Adaptação, pois esse é o seu cerne. Já vi muitas equipes não realizarem as retrospectivas e portanto não evoluírem seus processos de gerenciamento e desenvolvimento de software. As pessoas tendem a ignorar que o maior motivo de termos tantos softwares inúteis ou mal acabados é por falta de comunicação, seja com o cliente, com o chefe ou entre os desenvolvedores. E a retrospectiva é justamente uma oportunidade formal da equipe se comunicar e se aprimorar enquanto time ágil.

Principalmente os programadores, profissionais das ciências exatas, não gostam da ideia de “perder tempo” falando sobre os problemas do time ou pensando em processos, quando poderiam estar programando, que é o que gostam de fazer. Esse pensamento imaturo persistiu na minha mente durante alguns anos no início da minha carreira até que eu percebi que o software pelo software não adianta de nada. Que o que fazia (programar) era apenas um meio, e não o fim. Se meu software não solucionasse o problema do cliente, ele era apenas um monte de lixo, por mais tempo e esforço que eu tivesse colocado em seu desenvolvimento.

Parar e refletir sobre os objetivos e sobre os processos necessários para chegar lá é vital para a eficiência (e muitas vezes para eficácia também) do time.

#2 – Como facilitar uma Retrospectiva?

Como todas reuniões, o Scrum Master costuma ser o facilitador desta reunião de até 3h para Sprints de um mês. Ele deve convocar o time, explicar o motivo da reunião e focar-se auxiliar o andamento da mesma e o respeito ao tempo limite. Todo o Time Scrum participa ativamente desta reunião e a dinâmica abaixo é um exemplo de como ela pode ser conduzida, uma vez que o Scrum Guide apenas dá linhas gerais, sem um exemplo prático.

Escolha uma sala da empresa com quadro branco com canetas marcadoras (também chamados de “caneta para quadro branco” ou “pincéis atômicos”) ou na ausência desse recurso, um mural que possa ser riscado já serve. Vamos precisar também de post-its (se tiver 3 cores diferentes, melhor) e canetas esferográficas comuns. Na ausência de post-its, recorte pequenos cartões do tamanho de um cartão de visita que já resolve. Um bom número é 3 cartões/post-its por pessoa do time de desenvolvimento.

Divida o quadro/mural em três colunas: BOM, MELHORAR e AÇÕES.

Na coluna BOM devemos colocar cartões com aquilo que foi executado e que deu certo, que a equipe deveria manter na próxima sprint como uma boa prática.

Na coluna MELHORAR devemos colocar cartões com aquilo que foi executado de maneira ruim e que pode melhorar na próxima sprint.

Para cada coisa que precisa melhorar, rediscute-se novamente suas causas e o que pode ser feito para resolver, criando um registro na coluna AÇÕES com uma ação concreta e factível para o mesmo. Tem que ser algo que possa de fato ser colocado em prática, preferencialmente que alguém da equipe se comprometa pessoalmente de que não irá acontecer na próxima sprint.

As regras de preenchimento são: apenas um fala por vez, e somente aquele que estiver portando um token, que geralmente é um marcador de quadro branco ou caneta, previamente escolhida. Quando a pessoa fala (o que não deve demorar mais de 1 minuto por pessoa) o que deseja, ela escreve em um cartão/post-it de forma resumida e gruda no quadro/mural na coluna que tem a ver com sua contribuição. A próxima pede o token para poder começar a falar até que todos tenham falado ao menos uma vez.

Ao término da retrospectiva o Scrum Master coleta os dados e verifica com o time quais ações de melhoria já podem ser feitas na próxima sprint e quem vai fazê-las, garantindo que se tornem realidade. É comum guardar os cartões para “cobrança” posterior ou ao menos uma foto do quadro completo, que permita zoom depois para ler os cartões.

#3 – Ações Concretas

Talvez o ponto mais crítico da retrospectiva seja as ações definidas para melhorar o processo. Como Scrum Master, é seu dever garantir que os itens que “devem melhorar” não retornem na próxima retrospectiva, caso contrário o pilar da “adaptação” do Scrum não estará sendo aplicado e o processo, que deveria ser vivo, ficará estagnado. Via de regra, para cada item que está na coluna “MELHORAR” deve ter um item na coluna “AÇÕES” para resolver o problema. E aqui que mora o problema: as ações devem ser concretas.

O que diferencia uma ação concreta de uma abstrata?

Imagine que algo que deve melhorar é a comunicação com o PO, que representa o cliente da equipe. Que algumas features tiveram de ter retrabalho porque não atenderam às necessidades do cliente, sendo que trazer essas necessidades pro time é responsabilidade do PO que não esteve presente. Isso certamente deve melhorar para que a qualidade das entregas igualmente melhore. Assim, para esse item que deve melhorar devemos ter uma ação concreta para que não ocorra novamente. Certamente alguém irá sugerir “conversar mais com o PO”, mas note como isso é vago, em contraponto, uma ação concreta seria “marcar uma reunião semanal com o PO para alinhar a execução das features” e mais do que isso “definir que todas segundas-feiras às 11h teremos uma reunião de 30 minutos com o PO para mostrar como estão sendo desenvolvidas as features que estão em DOING no Kanban“. Percebe a diferença?

É difícil chegar nesse nível de ação concreta, mas é o que devemos buscar. Cabe ao Scrum Master tensionar a reunião para que as ações tenham esse nível de qualidade para que de fato elas sejam postas em práticas e o processo seja melhorado. Perguntas como: “Como? Quando? Quem?” devem ser instigadas até que a ação seja refinada neste nível de detalhe.

No entanto, um alerta: jamais defina ações, que por mais precisas que sejam e por mais boa intenção que tenham, sejam inexequíveis, isto é, não tenham como ser executadas. Quando uma ação é definida, o time inteiro está se comprometendo com ela e caso a ação seja impossível de ser realizada, haverá frustração quando os mesmos problemas voltarem a acontecer. Então defina ações que resolvam o problema e que sejam concretas, precisas, mas jamais inexequíveis.

Usando o mesmo exemplo anterior, do PO ausente, de nada adianta definir que as reuniões ocorrerão todas as segundas às 11h se o PO não pode nesse horário. Nesse caso, uma ação concreta mais facilmente executável seria “conversar hoje, logo após esta reunião, com o PO para definir um dia e horário semanal que ele possa estar presente na equipe para discutirmos o andamento das tarefas”. Mas note que ainda é uma ação precisa: hoje falaremos com ele, hoje marcaremos um dia e hora semanal na agenda dele para conversar com a gente.

E aí, mais confiante de aplicar Scrum na sua empresa?

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!