Retrospectiva.md

O que é retrospectiva?

A retrospectiva é o momento de melhoria contínua; é quando levantamos pontos positivos e negativos.

É o último time-box da Sprint. O primeiro é o planning, o segundo o desenvolvimento, o terceiro a Review e o último é Retrospective. Após finalizarmos a última etapa emendamos uma nova Sprint e as próximas iterações do processo.

A reunião de retrospectiva é a mais importante, pois é por meio dela que é possível exprimir o que afinal é agilidade. Esta reunião fornece a possibilidade de melhoria contínua em que pode-se "lavar roupa suja" para nos reinventarmos para uma próxima Sprint. O problema não é errar, é ficar enroscado sempre no mesmo problema, no mesmo erro! Quando essa situação ocorre é um desperdício de tempo e esforço.

Versões mais novas do "Scrum Guide" afirmam que a cada duas semanas de Sprint deve ser feita 1h30 de retrospectiva. A versão anterior do Scrum determina que a retrospectiva deve equivaler a 5% da Sprint, ou seja, igual a 2h a cada semana de Sprint. Particularmente, o investimento nas melhoras é algo que deve ser feito com certa constância, portanto, a versão anterior que traz a diretriz de 5% do tempo é mais adequada.

É preciso lembrar que retrospectiva não deixa de ser um time-box, portanto seu tempo de duração é rígido. Então, é bom fazer uso consciente desse tempo.

Retrospectiva é uma reunião na qual o time conversa, e dela participam:

• Desenvolvedores
• Scrum Master
• Product Owner
• A não ser que exista uma razão muito forte para violar essa formação, são essas as pessoas que a compõem.

Apesar de às vezes o time ter receio da presença do Scrum Master na reunião, o ideal é que a equipe seja capaz de falar francamente com todos.

Para começar a retrospectiva, iniciamos citando o Prime Directive, inclusive vários facilitadores da comunidade ágil mundial iniciam assim. Prime Directive é a diretiva primária, que resume-se a um parágrafo com o seguinte conteúdo: não importa o que descobriremos nessa reunião, consideraremos que as pessoas agiram dessa forma devido aos conhecimentos que possuíam na época, tempo e recursos disponíveis. Considerando esses aspectos, as pessoas fizeram seu melhor, e agora devemos seguir adiante.

Algumas empresas criam adesivos de parede com os dizeres da Prime Directive, justamente para que o time visualize com facilidade a mensagem. Retrospectiva é um momento de verificarmos as possibilidades para melhorar na próxima iteração, em um mesmo projeto e com o mesmo time e contexto. Todos devem saber que é um momento de melhoria contínua, não um momento de apontar culpados.

A ideia de uma Retrospectiva é pôr em prática o conceito de melhoria contínua. Nessa reunião, o time todo (PO, Scrum Master e Desenvolvedores) se foca em descobrir como melhorar ainda mais o time, o processo e o projeto já na próxima Sprint.

Há diversas mecânicas para essa reunião. Para saber mais sobre elas, você sempre pode olhar referências como o blog Fun Retrospectives (https://www.funretrospectives.com/) ou a Retrospectives Wiki(http://retrospectivewiki.org/).

Ações e Sugestões:

Uma forma muito comum de fazê-lo é deixar espaço para que todos falem ou façam perguntas. Porém, se há alguém tímido, ele provavelmente não se sentirá à vontade para participar. Uma estratégia é entregar canetas e post-its para todos e pedir para que anotem pontos positivos e negativos: um ponto por post-it. O facilitador da reunião pode passar e recolher esses papéis, ele mesmo colocando-os na lousa. Dependendo da maturidade do time, e se os integrantes não tiverem medo de falar, ele mesmo pode pegar o papel e colocar na lousa.

Mostrando post-its separados, Os post-its podem ser agrupados caso os assuntos sejam parecidos. Esses grupos de post-its criam o que chamamos de clusters.

É importante também notar que a lista de itens a fazer que sai de uma retrospectiva contém apenas ações, isto é, atividades que membros do time vão efetivamente fazer para obter algum resultado.

Note que o time não pode decidir que o cliente vá mudar seu comportamento ou que outra área da empresa vá passar a ajudá-los. Essas não são ações, são desejos de que algo magicamente vá mudar. No mundo da agilidade, isso é frequentemente chamado de wishful thinking.

Ações, por outro lado, envolvem os membros do time.

Se o problema em questão é que o cliente desaparece e não conseguimos tirar dúvidas com eles:

• desejo: o cliente vai entender a importância de estar presente

• uma ação: o Scrum Master vai explicar as perdas e ganhos de uma maior participação do cliente

• outra ação: em toda história daqui para a frente, haverá também o contato de quem pode sanar dúvidas dos desenvolvedores desse item em particular.

O resultado de uma retrospectiva é uma lista, preferencialmente curta, de ações que serão tomadas durante o próximo Sprint para melhorar ainda mais o time e o andamento do projeto.

Por onde começar?

Começando com resultados positivos tudo tende a se manter igual. Isto é, se está bom, continua bom, e se está ruim, continua ruim. Então, vamos iniciar abordando os aspectos negativos (mas a escolha de por onde começar depende de vocês!)

Supondo que iniciamos pelos pontos negativos, com vários post-its indicando que o cliente sumiu, enquanto a equipe precisava tirar diversas dúvidas com ele. Como agir diante dessa situação? O desdobramento poderia ser um muro de lamentações por parte da equipe, ou alguns integrantes poderiam partir para o famoso wishful thinking, pensando de maneira positiva para que a situação não se repita e... Nem preciso continuar para saber que essa é uma má ideia, e um caminho inadequado!

A partir da retrospectiva devem sair ações! Tanto dos pontos negativos quanto dos positivos.

No caso dos aspectos negativos levantados, qual deve ser a ação para que o problema diminua ou até desapareça no futuro?

No caso do cliente ter sumido, o que poderia ser feito?

Uma ação possível é o scrum master conversar com o cliente, explicando que suas ações acarretam em grandes impactos no projeto como um todo, portanto, o fato dele sumir no meio de uma iteração tem consequências. Ou então decidimos que o P.O. se informará melhor, mas isso pode causar mais trabalho para ele, que já está atolado de afazeres.

A solução seria ele coletar especificações mais detalhadas para que não precise mais falar com o cliente. Ou utilizamos o "chato da vez", a pessoa que ficará em contato direto com os clientes insistindo para que ele fale conosco. Ou podemos pedir para o cliente acessar diretamente o usuário, que quer muito que a funcionalidade seja desenvolvida.

Algo que já optamos fazer e até certo ponto arriscamos, e que acabou dando certo é: se o cliente não tem tempo para nos atender é porque a funcionalidade talvez não seja tão importante. Portanto, estabelecemos como regra de que, diante dessa situação, não iríamos desenvolvê-la.

As pessoas normalmente acostumam-se com qualquer restrição. Algumas são aceitas e outras não, claro. Mas dependendo da restrição, o público, cliente e usuários aprendem a lidar.

Voltando a falar de ações, independente daquilo que a equipe pensou depois da retrospectiva, é preciso deixar isso visível na área de trabalho do time (seja em ambiente virtual ou físico).

Na próxima retrospectiva, antes mesmo de levantar pontos positivos ou negativos, vamos verificar o que foi estabelecido como ação. Elas foram feitas? Deixaram de ser feitas? Melhorou? Eram necessárias? Ou seja, buscaremos aprender com as ações passadas.