Retrospectiva: Revisão de resultado e lições aprendidas ou reunião para lavar roupa suja?

A retrospectiva é uma das cerimônias mais importantes utilizadas em projetos ágeis. Ela deve ocorrer ao término da sprint, ou seja, o que determina sua frequência é o tamanho da sprint; a sprint pode variar seu tamanho de 2 a 4 semanas, e é este período que irá ditar a distância entre uma retrospectiva e outra. O ideal é que ela ocorra sempre ao término da sprint, para que os assuntos a serem discutidos não se acumulem.

Segundo o [ISTQB_FL_SYL CTFL AT] (syllabus_ctfl_at_2014br):
” - é uma reunião realizada no final de cada iteração para discutir o que foi bem sucedido, o que poderia ser melhorado e como incorporar as melhorias e preservar os êxitos em iterações futuras.”

Nesta reunião tópicos relacionados a testes, desenvolvimento, processos, ferramentas, riscos, pessoas, etc., podem ser abordados. E é neste momento que a reunião pode tomar um rumo inesperado. Em alguns casos, quando o moderador da reunião não detêm a experiência para conduzir a conversa de forma “neutra”, e orientar o time para tal atitude, a forma com a qual o assunto é levantado pode despertar uma discussão não produtiva, e virar mais um jogo de “vamos encontrar o culpado”.

A reunião de retrospectiva deve ser vista como uma oportunidade de comunicação e entrosamento entre o time, claro que, a cada execução de uma rodada de retrospectiva o time torna-se mais maduro, e consegue avaliar as lições aprendidas, tomar ação em relação as mesmas e propor possíveis soluções.

Vamos refletir com um exemplo fácil de ocorrer com qualquer time:
Cenário: Digamos que em uma determinada sprint o time de desenvolvimento não entregou a tempo a versão, e com isso o time de testes não conseguiu concluir a tempo a execução do ciclo de regressão, concuminando em uma entrega mal sucedida.

Se os testadores e desenvolvedores utilizassem a reunião de retrospectiva como uma reunião para “lavar roupa suja”, os tópicos apresentados na reunião seriam mais ou menos assim:

“Time de desenvolvimento não entregou a versão a tempo”
“Time de testes não executou os testes na versão a tempo”
“Fulano teve muitos bugs reabertos”
“Beltrano não soube testar a estória”

E assim por diante…

Porém, se o time é maduro e a reunião de retrospectiva é efetuada de forma correta, os tópicos seriam mais ou menos assim:

“Cliente insatisfeito com a entrega.”
“Não conseguimos entregar a versão na data esperada.”
“Estimamos de forma errada as atividades”
“Planejamento não foi correto”

E assim por diante…

O que quero dizer com isto, o primeiro pensamento do time deve ser o cliente; quando a reunião de retrospectiva é utilizada da forma correta - como uma revisão de resultados e lições aprendidas, ela é uma ferramenta importantíssima para o alinhamento das expectativas do time, e o resultado do projeto.

Utilizando a situação acima, a maior lição aprendida do nosso cenário foi a falha de planejamento. E uma vez que o planejamento envolve representantes de desenvolvimento, representantes de testes e representantes do cliente, o time como um todo falhou, e não uma parte ou uma pessoa dele. O time deve se encontrar, vivenciar e se guiar pelos mesmos objetivos, se uma parte falha, é culpa de todos, é uma lição aprendida e potencialmente uma oportunidade de melhoria.

Michelle dos Santos – Analista de testes SR (FIT – Flextronics Institute Technology)

Realmente é comum que reuniões de retrospectivas percam o controle e virem reunião para “lavar roupa suja”.

O que me preocupou no seu texto foi o cenário de exemplo. Isso de separar “time de desenvolvimento” e “time de teste” vai completamente contra tudo que Agile prega em geral. O ponto de “não entregar a tempo a versão” soa como um processo waterfall.

Em um processo ágil, não existe “time de dev”, “time de teste”, etc, existe apenas o time. Quando temos o papel de tester dentro de um time ágil, esse problema de “não entregar a tempo a versão” não existe mais, porque o tester deve atuar a cada história fazendo suas atividades (testes exploratórios, automação no nível de API/UI/etc, testes não funcionais, etc). E o mais importante disso tudo é que as atividades do tester devem ser parte da DoD (definition of done - definição de “pronto”), ou seja, nenhuma história deve ser dada como “feita” sem que tenha sido passada pelas atividades do papel de tester.

Abs

@stefanteixeira
Muito obrigada pelo seu comentário!
Os termos utilizados foram mais para exemplificar o cenário egoísta que muitas das vezes vivenciamos nos projetos, mesmo ele sendo ágil. No caso de um time independente de testes isso é muito comum.

tb discordo que esses cenários sejam “base” de uma equipe ágil…

Mas eu sou muito a favor de “lavar roupa suja” na retrospectiva.
Time bem alinhado e que não tem papas na lingua é um time mais eficiente…

Agora apontar o dedo e dizer que fulano é feio e bobo não resolve…

E pelo que eu saiba… o “moderador” é o próprio scrum master… se ele não sabe fazer uma retro… então ele não deveria ocupar esse papel… :P

@MiSantos - Realmente, o que mais acontece por ai são equipes colocando papéis do time (tester, Dev, P.O, etc…) como “root cause” dos problemas de entrega. Mas o mais me preocupa de verdade não é nem a questão de “lavar roupa suja” em Retrospectiva (o que no meu ponto de vista não é o comportamento ideal), e sim a omissão de feedbacks e comunicação transparente DURANTE a sprint.

Ou seja, se os membros da equipe só estão comunicando ou tentando identificar as possíveis causas dos problemas que são claramente visíveis durante a sprint, somente no momento da Retrospectiva, ai então temos uma equipe obviamente disfuncional.

E tirando as referências de Syllabus e etc… Como tem sido as experiencias em Retrospectivas da sua equipe? (relatos de cenários reais são sempre bem vindos)

@Eduardo.Oliver
Olá Eduardo! Obrigada por comentar
Vivemos os dois cenários. Tivemos uma experiência com um Scrum master que “pregava” que o correto era lavar roupa suja, apontar o dedo e etc. O que causou um resultado catastrófico no time ( e quando falo time, não é time de testes, é time do projeto, independente de papéis), acredito que por vários motivos, imaturidade do time pode ser um deles, e outra apontar o dedo mexe com o brio da pessoa, com o ego, e não enobrece a discussão na maioria das vezes. Ela acaba resultando no afastamento das pessoas, que foi o que vivemos, e não na descoberta de uma lição aprendida, o pensar em uma possível solução.
E hoje vivemos uma situação contrária, onde a retrospectiva é utilizada para elevarmos os bons resultados e colhermos o feedback, preocupações e problemas enfrentados pelo time. Com esta diretriz as coisas fluem melhor, as pessoas se fazem ouvir, tem oportunidade de falar, não se sentem oprimidas. Anteriormente utilizavamos o trello e as pessoas ja liam os cartões antes para irem preparadas para a “briga”, a defesa…hoje, até leêm antes, mas já com um pensamento diferente, de não “justificar”, mas sim buscar uma proposta de inovação e solução. E com base nesta experiência que escrevi o texto…

@MiSantos
Michelle, essa discussão me lembrou de uma palestra fantástica que assisti sobre técnicas de facilitação em times ágeis, do Marcos Garrido (Knowledge21): http://pt.slideshare.net/marcosgarrdio/tecnicas-de-facilitao-slideshare

Vale muito a pena dar uma olhada, com certeza você já deve ter encontrado no seu time (ou em um time antigo) algum perfil que ele menciona.

Abs

@stefanteixeira
Obrigada, vou ver o material.

Bom artigo, interessante a discussão. Levantar ações para serem tomadas e executar essas ações é um desafio. Encontrei uma referência legal para isso = http://www.benlinders.com/2015/getting-retrospective-actions-done/

Abs

Acredito que tenha uma grande diferença entre lavar roupa suja e apontar o dedo, principalmente de pessoa para pessoa. Quando penso em lavar roupa suja o cenário fica desta forma: “levantar todos os resultados que não atingiram as expectativas (do time e/ou do cliente); analisar e encontrar as causas raízes desses resultados; alinhar e estabelecer um plano de ação” e apontar o dedo é simplesmente buscar um culpado.

Olhando nesse contexto acredito que a “Retrô” deve ser utilizada também para lavar a roupa suja.

Acredito que um dos principais erros dos times é falta do Feedback durante a Sprint, como o @Eduardo-Oliver falou. Essa comunicação durante a sprint permite que o time comece a corrigir as falhas já levantadas, gerando menos estresse na retrô e aumentando a chance de melhores resultados.

Outro ponto é a questão da interpretação, de 4 exemplos que foram citados como incorretos, particularmente, consigo observar pontos de atenção:
“Fulano teve muitos bugs reabertos” - São bug’s recorrentes? Foi testado direito? Corrigiram com o cotovelo? “Fulano” está desmotivado? A US foi bem escrita? Critérios de aceite bem definidos? O time está falando a mesma língua quando se fala do produto? Como está a comunicação dos Devs? Estão respeitando os processos estabelecidos para a Sprint?
“Beltrano não soube testar a estória” - A US está clara e objetiva? As reuniões de Grooming/Planning estão entregando valor? “Beltrano” está distante do time? Foi uma falha técnica ou de negócio? Só “Beltrano” está com dificuldades? Ele procurou ajuda?

(Pontos que eu levantaria no contexto que trabalho hoje)

Uma outra coisa interessante é deixar o “By the book” de lado e adaptar/ajustar as reuniões, técnicas, padrões e etc para o contexto que está inserido (Time).

"Atenciosamente",
Gustavo Lui.

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.