Um método simples para retrospectivas
Provavelmente existem tantas maneiras de conduzir uma retrospectiva quanto equipes que trabalham com retrospectivas. Hoje quero descrever meu método favorito, especialmente porque é uma abordagem comprovada que funciona bem há anos para muitas Equipes Scrum.
Começar, parar, continuar
Minha forma preferida de conduzir uma Retrospectiva de Sprint é perguntar aos membros da equipe quais coisas eles gostariam de começar, parar e continuar fazendo. Esse tipo de reunião é conhecido como reunião "começar, parar, continuar".
As coisas que uma equipe quer começar são aquelas que devem ser adicionadas ao processo. Aqui estão alguns exemplos:
Apresentar o software aos clientes o mais cedo possível.
Especificar os testes de aceitação cedo e em conjunto com os clientes.
Realizar inspeções de código.
Comparecer pontualmente aos Daily Standups.
Concluir uma story antes de começar a próxima.
A equipe deveria parar de fazer coisas que os membros consideram ineficientes ou perda de tempo. Exemplos de retrospectivas anteriores são:
Inserir código sem ter certeza de que todos os testes serão bem-sucedidos.
Levar mais de 15 minutos nas Daily Scrum Meetings.
Pular as reuniões de Product Backlog Refinement quando estamos atrasados no final do Sprint.
Entre as coisas que uma equipe deve continuar fazendo está tudo aquilo que a equipe quer continuar valorizando, mas que ainda não se tornou um hábito. Portanto, qualquer item das listas "Começar" e "Parar" pode teoricamente ser transferido para esta lista e permanecer nela por alguns Sprints.
Por fim, esses itens são removidos da lista "Continuar" assim que se tornam hábitos. Caso contrário, a lista ficaria longa demais.
Diferentes abordagens para a geração de ideias
Um Scrum Master pode perguntar aos membros da equipe de várias formas o que querem começar, parar e continuar fazendo. A forma mais simples é dizer: "Digam o que vier à mente". Os membros da equipe podem então compartilhar suas ideias livremente, conforme surgem, independentemente de qual das três listas pertencem. Esse é o meu método padrão.
No entanto, depois de alguns sprints, isso pode ficar um pouco monótono. Então, de vez em quando, trago um pouco de dinamismo percorrendo a sala e pedindo a cada pessoa que me diga um ponto. Às vezes faço duas rodadas antes de aceitar ideias adicionais.
Outras vezes, prefiro focar em uma categoria específica das três; frequentemente são as coisas que a equipe deveria parar de fazer. Então peço aos membros da equipe que me digam apenas as coisas que querem parar de fazer. Ou combino as diferentes abordagens e peço a cada pessoa individualmente que identifique algo que deveria ser interrompido no processo atual da equipe.
Existem tantas possibilidades para tornar a geração de ideias nessas retrospectivas mais variada que demora bastante até ficar entediante ou monótono.
Votar nos pontos
Depois de coletar ideias suficientes, os membros da equipe devem votar no ponto ou pontos mais importantes. Frequentemente é bem óbvio quando é hora de votar, nomeadamente quando a criatividade diminui e quase não surgem mais ideias novas.
O Scrum Master pode então pedir aos membros da equipe que escolham apenas a ideia mais importante para eles ou várias ideias. Qual abordagem o Scrum Master quer usar fica a critério dele. Por exemplo, pode-se dar a cada membro da equipe três votos para distribuir como quiserem (podendo ser todos os três votos para o mesmo ponto).
Eu gosto desse direito de voto múltiplo em retrospectivas. A maioria dos pontos que surgem numa retrospectiva não leva realmente muito tempo; eles se referem mais a comportamentos específicos. Um exemplo dos pontos mencionados acima seria chegar pontualmente aos Daily Standups. Isso não leva tempo algum. Pelo contrário – até economiza tempo.
Uma escolha múltipla permite que a equipe trabalhe simultaneamente nesse comportamento e em alguns outros pontos. No entanto, em princípio eu não pegaria mais de três pontos de uma vez. Mesmo que não levem tempo (ou muito pouco), os pontos individuais podem perder importância se você se dedicar a muitos deles ao mesmo tempo.
Além de selecionar novos pontos a serem acompanhados, também deve ser discutido quais pontos da lista "Continuar" já foram cumpridos, não são mais necessários ou podem ser removidos da lista por outros motivos.
A próxima retrospectiva
Eu recomendo que o Scrum Master traga a lista de ideias da última retrospectiva para a próxima retrospectiva; isso se aplica tanto às coisas que devem ser trabalhadas quanto às que não devem ser trabalhadas. Isso ajudará a iniciar a discussão para a próxima retrospectiva.
Na maioria das vezes, simplesmente escrevo os pontos em uma folha grande de papel e penduro na parede sem muito alarde ou discussões. O objetivo é apenas que os pontos individuais estejam lá quando a equipe precisar deles ou quiser retomá-los. Então começo uma nova discussão "Começar, parar, continuar".
Vantagens deste método
Eu acho que esta é uma forma muito rápida, simples e segura de conduzir uma retrospectiva, que além disso funciona bem. Uma reunião assim é muito orientada para a ação. Você não gasta tempo se concentrando em sentimentos. Os membros da equipe não são perguntados como se sentiram durante o sprint – estavam satisfeitos ou tristes, se sentiram bem ou desconfortáveis?
Cada ponto identificado levará diretamente a uma mudança de comportamento. A equipe vai começar algo, parar algo ou continuar fazendo até que se torne um hábito.
Consigo imaginar bem que muitas pessoas agora dirão que é importante primeiro falar sobre os sentimentos dos membros da equipe ou que não podemos saber como agir antes de primeiro abordarmos os sentimentos das pessoas. Faça isso tranquilamente. Em alguns casos, isso pode fazer sentido. Em muitas outras situações, porém, podemos identificar diretamente o que deveríamos fazer (por exemplo, começar a testar mais cedo).
Essa é a grande vantagem da abordagem "Começar, parar, continuar" para Sprint Retrospectives.
