A Sprint Retrospective é a oportunidade para todo o Scrum Team (Product Owner, ScrumMaster, e Development Team) para se inspecionar e criar um plano de ação para as melhorias para a próxima Sprint.
1. Excelente ScrumMaster = Excelente Retrospectiva
Tudo o que você precisa é de um excelente ScrumMaster
Existem milhares de técnicas de retrospectiva publicadas em livros e em blogs que quando BEM aplicadas alcançam resultados maravilhosos. A questão principal é saber como e quando aplicar uma determinada técnica ou fluxo ao invés de outra.
Eu sou muito fã da técnica StarFish e recomendo para os ScrumMasters iniciantes e experientes a utilização desta técnica. Pois já tive momentos bons assim como já vi colegas tendo resultados empolgantes com essa técnica.
Mas confesso que nem sempre tenho sucesso ao aplicar essa técnica e que o sucesso veio com a pratica. Pois a questão principal não era saber apenas a técnica e sim saber como facilitar uma retrospectiva.
Alguns colegas dizem que musculatura de retrospectiva só se ganha com o tempo, a pratica e a vontade de melhorar a facilitação. E assim se tornaram melhores facilitadores e suas Sprint Retrospectives se tornaram cada vez melhores assim como os seus Scrum Teams.
E finalmente o Certified Scrum Trainer Alan Cyment vai alem ao dizer que tudo que o Scrum precisa é de um excelente ScrumMaster para começar a fazer Sprint Retrospectives. Por isso espero que as próximas dicas te ajudem a se tornar um excelente ScrumMaster.
2. Faça a Sprint Retrospective em um momento auspicioso
Uma Sprint não precisa terminar as Sextas
Existe uma tendência de se iniciar Sprints as segundas e terminar as sextas, todavia isto pode não funcionar.
E qual o problema de se fazer a Sprint Retrospective as Sextas?
O seu Development Team pode estar cansado de uma semana intensa de trabalho e participar apenas fisicamente da reunião e terá problemas para manter a presença mental na reunião.
Dependendo do horário da Sprint Review e da Sprint Retrospective alguns times ficam compelidos a fazer trabalhos complexos como implantação e testes exploratórios em um dia em que o foco pode estar no final de semana. Isso se não for encontrado um bug e o resultado da Sprint não for como o esperado.
E dependendo do que é falado na Sprint Retrospective muitos finais de semanas podem ser estragados, ou ainda, algumas situações podem ficar piores…
E finalmente, Estudos mostram que a sexta-feira tem uma ligação forte com os conceitos de “Liberdade” e “Partir”. De certa forma, sexta-feira é o dia que tipicamente as pessoas estão mais focadas em no fim de semana do que em qualquer outro tema. Basta lembrar quantas vezes na sexta-feira o assunto do seu Scrum Team é o final se semana.
Sprint Retrospectives na Sexta-Feira funciona em muitos Scrum Teams, todavia isso pode não ocorrer no seu ambiente de trabalho.
3. O corpo fala
Escute as palavras e veja o real significado
Infelizmente ainda não é possível saber o que outra pessoa está pensando. Dessa forma entender as reais intenções de uma pessoa é algo que beira o impossível.
Podemos ter um melhor entendimento das reais intenções das pessoas por meio das expressões corporais. Por exemplo:
Braços cruzados podem significar desde uma postura defensiva ou de insegurança até uma postura de hostilidade. Uma posição relaxada com braços e pernas ligeiramente abertas demonstra autoconfiança e segurança. Já uma postura recolhida significa tédio.
Movimentos de cabeça de um lado para o outro significam negação, já movimentos de cabeça para cima e para baixo consentimento. Uma postura erguida demonstra segurança, valor e importância no que você está fazendo. E mãos na cintura significam desafio, agressividade.
Alguns sinais corporais podem trazer impressões incorretas, todavia desconsiderar essas informações valiosas em uma facilitação pode levar a resultados desastrosos.
Em outras palavras, comece a ler o Best Seller “O Corpo Fala – A Linguagem Silenciosa da Comunicação Não-verbal” do Pierre Weil e do Roland Tompakow.
4. Presença obrigatória do Product Owner
A participação do Product Owner é essencial na Sprint Retrospective
O Product Owner é obrigado a participar da Sprint Retrospective. E acredite isto está escrito no Scrum Guide. A primeira frase do Scrum Guide sobre a Sprint Retrospective é a seguinte:
“A Sprint Retrospective é uma oportunidade para que o Scrum Team inspecionar a si próprio e criar um plano de melhorias para ser aplicado na próxima Sprint.”
Tendo em vista que o Scrum Team é compreendido pelos três papeis do Scrum incluindo o próprio Product Owner. A presença do Product Owner é obrigatória, seu Scrum Team gostando ou não.
A questão principal é que existe a responsabilidade do ScrumMaster em garantir a segurança psicologia de todos os envolvidos durante a Sprint Retrospective.
Por exemplo, com frequência o Development Team não se sente à vontade em frente ao Product Owner, por questões que vão desde arrogância, hierarquia, desconfiança, dentre outras. Nestes casos Peter Hundermark recomenda que, temporariamente, o Product Owner não participe das Sprint Retrospectives e o ScrumMaster trabalhe em paralelo estas questões objetivando a segurança psicológica da reunião.
Vale lembrar que o Scrum demanda muito trabalho do Product Owner e estes precisam ser capazes de colaborar com a melhoria continua dos processos dentro do Scrum. Como exemplo de processos em que o Product Owner é essencial tem-se a priorização e a preparação dos itens do Product Backlog e o relacionamento com os Stakeholders.
5. Não buscar culpados
Diga não à caça às bruxas!
Um dos maiores receios ao se entrar em uma Sprint Retrospective é o de que a reunião se torne uma sessão de caça às bruxas, onde a única coisa que importa é buscar culpados.
Claramente tal atitude não contribuirá para a evolução do time ou para um melhor desempenho coletivo. Com esse raciocínio Norman Keath define a primeira diretiva de uma boa Sprint Retrospective como:
“Independentemente do que descobrirmos, nós entendemos e realmente acreditamos que todos fizeram o melhor que podiam, dado o que eles sabiam no momento, as suas competências e capacidades, os recursos disponíveis, bem como a situação na mão. ”
Dessa forma a chave para uma Sprint Retrospective bem-sucedida e construtiva é garantir que todos os participantes estejam de acordo com essa diretiva. E assim teremos um tão sonhado evento de aprendizagem coletiva que irá dar bons resultados no longo prazo.
6. Checar e Atuar
Sempre há algo a melhorar no processo
O mais importante de uma Sprint Retrospective é o comprometimento dos envolvidos com as melhorias do processo de desenvolvimento de software.
No Scrum temos diversos ciclos de PDCA (Plan-Do-Check-Act) sendo executados com diferentes objetivos. Na Sprint Retrospective é feito o Checagem do processo e a criação de um plano de ação para melhorias.
Jean Tabaka menciona que sair de uma Sprint Retrospective sem um plano de ação é uma das maiores falhas possíveis, mas de nada adianta criar um plano de ação e este não for foco de atuação durante a próxima iteração.
Existem estratégias como um backlog de melhorias, expor o plano de ação em local visível, e pedir para todos os envolvidos escrever o plano de ação auxiliam na implementação das melhorias. O ScrumMaster deve guiar a melhoria dos processos, todavia deve haver o comprometimento de todos os membros do Scrum Team com a melhoria continua de processos.
Jeff Sutherland finaliza neste vídeo com a seguinte definição de Sprint Retrospective:
“ A Sprint Retrospective é desenhada para corrigir o problema mais importante. E quando isso ocorre, o Development Team acelera e começa a ir mais rápido, assim como a qualidade também aumenta. Dessa forma a Sprint Retrospective é crítica para o aumento da performance do Development Team.”.
___________________________________________________________________________________________________________________
Gostou? Aqui você encontra as outras 6 dias para tornar a sua Sprint Retrospective ainda mais eficiente.
Não esqueça de deixar seu comentário 😉
Facebook | Twitter | Linkedin | Youtube
Eu realmente não consigo concordar na “obrigatoriedade do P.O” na cerimônia da retrospectiva. Mesmo achando que ela seja eficiente para melhoria do time, processo e do produto, acredito que essa visão deva ser do time e que esta, não será necessariamente transparente ao product owner. Principalmente se este estiver do lado do cliente. Acredito que o nível de maturidade e de confiança entre ambos, estão intimamente ligados na avaliação da participação (ou não) do P.O. Até porque o P.O já deu seu feedback, sob a ótica do produto, na cerimonia do Review. Os artefatos de saida dela, poderão sim, entrar como insumo de discussão na retrospectiva.
Olá Vicente,
Mas no simulado para certificação de PO da scrum.org tem uma questão que afirma que o PO OBRIGATORIAMENTE deve participar da reunião de retrospectiva.