Dentro do framework Scrum, a retrospectiva é uma oportunidade para a equipe se inspecionar e criar um plano de melhorias que podem ser implementadas na próxima sprint. É nesse momento que o time fala sobre suas dores em relação a entrega e performance, que os colaboradores dão feedbacks, e que a visão do projeto é alinhada como um todo. Essa cerimônia se torna ainda mais importante quando o trabalho é remoto.
Nossos colaboradores já estão há três meses em home office. Além disso, o isolamento social (em virtude da pandemia de coronavírus) também pode influenciar o desempenho do time: em alguns momentos, as pessoas podem se sentir mais sensíveis, ansiosas ou até mesmo inseguras para falar sobre os problemas que ocorrem nos projetos. Para entender melhor como as retrospectivas podem ser uteis a esse momento , a Product Owner Iris Ferreira, em colaboração com outros POs, Gerente de Projetos e Agilistas, compartilhou com os colegas, no SoftDrops*, alguns relatos.
Como funciona a retrospectiva?
Ela ocorre após a revisão da última sprint e antes do planejamento da próxima. O Scrum Master garante que o evento aconteça e que os participantes compreendam o seu objetivo, incentivando a equipe a ser mais eficaz e saudável. É aconselhável que todos os membros do time participem.
“A Sprint Retrospective é uma oportunidade para o time inspecionar a si próprio e criar um plano de melhorias para ser aplicado na próxima sprint.”
(Scrum Guide)
O que se discute na retrospectiva?
Nesse rito, o time debate os acertos da sprint, e o que é possível melhorar para a próxima. É o momento ideal para pensar em soluções. A retrospectiva acontece conforme as seguintes etapas: Preparação > Reunião de dados > Geração de insights > Decidir o que fazer > Fechamento com plano de ação.
Dicas para uma boa retrospectiva
Na sua apresentação, Iris deu algumas dicas para se realizar uma retrospectiva eficaz. Uma delas, é fazer o rito em um momento auspicioso. É necessário que haja engajamento do time, que eles estejam em um ambiente seguro e com foco total na atividade, para que não ocorram falhas na comunicação.
Tendo isso em vista, quando os problemas são comunicados, a PO ressaltou que é importante não buscar culpados. Se, por alguma razão algo não deu certo, essa responsabilidade é do time como um todo.
“Independentemente do que descobrimos, nós entendemos e realmente acreditamos que todos fizeram o melhor que podiam, dado o que eles sabiam no momento, suas competências e capacidades, os recursos disponíveis, bem como a situação na mão.”
(Norman Kerth)
Além disso, Iris falou sobre a importância de checar e atuar. Sempre há algum item que pode ser melhorado no processo. Uma possibilidade é criar um backlog de melhorias, por exemplo. Esse é um ponto que pode ser conduzido pelo Scrum Master.
Retrospectivas na prática
Após contextualizar a retrospectiva e compartilhar algumas dicas, Iris apresentou alguns exemplos práticos, com a colaboração de alguns colegas.
TIME 1 – Retrospectiva focada em resolver problemas
Cenário: Time fechado e pouco colaborativo, acostumado a trabalhar sob comando e controle.
Problema: na Sprint em andamento, o time aceitou uma mudança a pedido do diretor. A tarefa foi colocada como prioridade máxima e uma estimativa de prazo foi dada sem consultar todo o time. Os itens que saíram da priorização não foram informados.
Resultado: o time não entregou nem o item novo, nem os demais.
Dinâmica na retrospectiva: a partir de um post it escrito “O item xyz foi adicionado à sprint”, o time escreveu as causas e os efeitos dessa ação. Conforme a equipe colocou no quadro as causas e efeitos, um grande mapa mental foi montado. Em seguida, causas que poderiam influenciar a montagem dos planos de ação foram escolhidas.
Conclusão: foi uma retrospectiva positiva, pois foi realista e claramente focada em resolver essas questões pendentes.
TIME 2 – Retrospectiva focada em visibilidade
Cenário: uma equipe com diversos bloqueios durante a sprint, por fatores externos ao time, em um ambiente escalado de dependências.
Problema: dar visibilidade ao que precisava ser escalado e o que o time necessitava resolver internamente.
Dinâmica na retrospectiva: foi desenhado um quadrante com os campos ‘o que está bom’, ‘o que não está bom’, ‘o que pode’ e ‘o que não pode’ ser resolvido pelo time.
Conclusão: após o time discutir os campos e os itens que se encaixavam em cada parte, foi possível separar o que era possível resolver entre os integrantes da equipe e as pendências que necessitavam ser discutidas com pessoas externas.
TIME 3 – Retrospectiva focada no time se conhecer
Cenário: o time ainda não havia trabalhado em conjunto, especialmente os desenvolvedores. No início do projeto o formato de trabalho mudou para o home office.
Problema: o time tinha receio em apresentar os pontos negativos, que estavam impactando nas entregas. A sprint falhou e o time não conseguiu alinhar a entrega.
Dinâmica na retrospectiva: foi utilizado um dashboard de retrospectiva, em uma ferramenta de comunicação interna, com os cards Feliz, Triste e Louco. Através dos cards Triste e Louco o time definiu um plano de ação para os casos mais críticos e que demandavam atividades mais efetivas. Conforme o projeto avançou, o time passou a sentir mais liberdade para falar dos problemas.
Conclusão: as sprints passaram a ser finalizadas com sucesso e a própria equipe concluiu que é necessário apontar as falhas. Dessa forma, todos evoluíram profissionalmente e contribuíram para o amadurecimento do time.
TIME 4 – Retrospectiva focada em resolver problemas
Cenário: um time novo, com pessoas que não se conheciam previamente. Não conseguiram terminar as sprints – que tinham objetivos propostos pela própria equipe.
Problema: na planning, as votações do poker foram altas e muitas histórias grandes entraram na sprint e o time não ganhou a velocidade adequada. Além disso, o cliente também solicitava mais histórias na sprint e elas entravam sem estar prontas. Isso gerou conflitos no time e impactou a previsão de entrega.
Dinâmica na retrospectiva: a partir da discussão sobre os pontos fracos e pontos de melhoria, o time opinou sobre o que necessitava ser revisado. Ocorreu uma extensa discussão sobre os processos do time e foram criadas ações, que melhoraram a performance, além de entregas com mais qualidade e valor.
Conclusão: essa revisão deixou o time alinhado quanto ao que deveria ser desenvolvido durante a sprint. A equipe passou a se envolver mais na tomada de decisão do projeto, empoderando os colaboradores e alinhando as expectativas de cada um.
*O SoftDrops é um evento de troca de conhecimento que acontece todas as quartas-feiras, na sede da SoftDesign. A cada semana, um colaborador se predispõe a expor para os colegas algum tema de seu interesse, que tenha relação com os três pilares do nosso negócio: design, agilidade e tecnologia. A minipalestra dura em torno de trinta minutos e é seguida por um bate-papo entre os participantes.
