Agile Retrospectives Antipatterns Que Scrum Masters Têm De Evitar

https://luis-goncalves.com/

Olá, esta semana vou falar sobre Agile Retrospectives Antipatterns. Como sabem, nas últimas semanas, tenho escrito sobre anti-padrões em, por exemplo, 20 Product Owners AntiPatterns ou 8 Agile, Scrum Antipatterns — Scrum Masters. Agora, é altura de falar sobre Agile Retrospetivas.

Este post será sobre: “Agile Retrospectives Antipatterns”. Também irei mencionar várias coisas às quais deve prestar atenção; já que também lhe podem acontecer. Estes são sinais que as suas retrospetivas estão a ser ineficazes.

Gostaria de sublinhar que muitas destas ideias vieram das seguintes fontes:

9 Agile Retrospectives Antipatterns

O QUE ACONTECE NA RETROSPECTVA, NÃO FICA NA RETROSPECTIVA

Vejo este Antipattern com alguma frequência. Por exemplo, numa empresa em que trabalhei no passado, a administração pediu para gravar as Agile Retrospetivas. O expectável seria que, se as retrospetivas fossem gravadas, outras equipas seriam capazes de aprender com os problemas dos seus pares.

Como deve imaginar, o resultado foi catastrófico, ninguém quis saber, as equipas já estavam ocupadas o suficiente com as suas próprias Retrospectives. O maior problema era que ninguém estava disponível para falar sobre os problemas, caso as Retrospectives fossem gravadas, sabiam que qualquer pessoa na organização podia ouvir essas sessões. Por isso, ninguém tocava nos problemas ”difíceis”.

Solução

As Agile Retrospetivas deve ser um lugar seguro. Só os membros da equipa devem participar na reunião; para abordar o problema anterior, itens de ação podem ser expostos em espaço público. No entanto, eu manteria as notas na equipa. Se a organização levar a sério a partilha de conhecimentos, pode suster uma comunidade de práticas. É a melhor abordagem para a partilha de conhecimento, em vez de forçar, de certa forma, as pessoas a partilhar os resultados com o resto da organização.

MUDAR O MUNDO

A equipa compromete-se com uma lista de ações ambiciosas, desconsiderando se há tempo para as alcançar na iteração seguinte. Isto leva a algum desapontamento, porque as ações não não são realizadas e a equipa adiciona ainda mais ações à lista na Retrospetiva.

Solução

Este anti-padrão é muito comum. A solução não é de todo difícil, Veja um dos meus posts, em que refiro que as equipas devem “Fazer pequenas mudanças, e mudar uma coisa de cada vez“.

Acredito que a coisa certa a fazer é simplesmente retirar um tópico de cada vez, das suas Retrospetivas. Selecionar um tópico, mas fazer uma análise adequada do mesmo. Compreender profundamente qual é a razão do problema em causa (pode usar técnicas como os “5 Whys”) e implementar a mudança durante a próxima iteração.

Seguindo esta abordagem, vai permitir que a equipa se concentre numa coisa de cada vez.

SEM TEMPO DE PROGREDIR

Depois da iteração, a equipa demora cinco a dez minutos, a ter uma breve conversa sobre como as coisas estão a correr e chama-a de Retrospetiva. Este é um sinal de que a equipa não vê quaisquer benefícios nas Retrospetivas. Quem tiver ideias para melhorar, com a ausência de um fórum para obter o apoio da equipa, tem de enfrentar uma luta para as implementar.

Solução

Aqui o papel do Scrum Master é muito importante. Se a equipa não vê o valor das Agile Retrospectives, talvez o coach deva organizar um workshop com a mesma, no sentido de explicar como e porquê as retrospetivas são muito importantes.

No caso de ser você o coach, tire o devido tempo para dizer à equipa o quão importante é a Agile Retrospective, mas lembre-se daquilo que mencionei no anti-padrão anterior: mude uma coisa de cada vez. Deixe a equipa ver os progressos e use o momento para reforçar a ideia do quão essenciais são as Agile Retrospectives.

NÃO SE ASSSUME RESPONSABILIDADE

A equipa passa a Retrospetiva a resmungar sobre como as coisas estão más, sem assumir responsabilidades para melhorar a situação. Isto pode ser catártico e libertar tensão na equipa, mas pode também rapidamente tornar-se um jogo de culpas. As Retrospetivas são sobre fazer mudanças para melhor, e isso não pode acontecer sem haver a discussão do que é que a equipa pode fazer.

Solução

Nesta situação, gosto de transferir a responsabilidade para a equipa. Deixá-los falar, mas a certo ponto colocar uma simples questão:

“O que é que vai fazer acerca da situação?”

Esta é normalmente uma situação muito poderosa. Envia uma mensagem muito clara para a equipa: se eles não fizerem nada, nada irá mudar. Vão ficar presos à sua frustração diária e ao mau ambiente que se gerou.

Normalmente, tentam acordar e definir algumas ações para corrigir o problema, mas muitas equipas acabam a dizer: “não podemos fazer nada, está fora do nosso controlo”. Não caia nessa armadilha! Há sempre algo que a equipa pode fazer para melhorar a situação. Seja imaginativo e ajude a equipa a encontrar as suas formas de resolver o problema, nunca permitindo que a Retrospetiva se torne numa sessão de queixas.

WISHFUL THINKING

As ações discutidas são algo vagas com nenhum iniciador como “melhorar a comunicação” ou “fazer mais refactoring”. Estas não são ações; são problemas nos quais se deve trabalhar. Sem discussão, a equipa não sabe o que fazer para implementar estas pseudo-ações.

Solução

Dispor os itens de ação de forma a que possam ser determinadas como “feitos” ou não-feitos. “Refactoring mais” não é uma tarefa útil, porque não sei pode dizer se está feito. “Melhorar o modelo do User do Code Climate da categoria F para D” é passível de ação e, por isso, a equipa, deve tomar pequenos passos que são atingíveis e ajudam no progresso.

Por exemplo, para por medidas objetivas na qualidade do código e performance, use Code Climate, Airplane, New Relic, Airbrake ou outros serviços de instrumentação.

OS GESTORES DE LINHA QUEREM PARTICIPAR

Por vezes, os gestores de linha querem participar nas Retrospetivas, para compreender o que se passa. Fazem-no com as melhores das intenções; só querem saber quais os problemas que existem para ajudar as equipas a resolvê-los.

Infelizmente, esta não é uma boa ideia. Como foi mencionado anteriormente, Agile Retrospectives são um lugar onde os membros da equipa têm de se sentir seguros. Este é um pré-requisito das Retrospetivas produtivas. Se os chefes de linha comparecerem à reunião, as pessoas sentir-se-ão com receio de falar.

Solução

A solução aqui é bastante fácil. Todos os Scrum Masters podem juntar-se e criar a regra de que mais ninguém, para além dos membros da equipa, pode participar nas Retrospetivas. Se a administração quer saber o que se passa nas Retrospetivas, o Scrum Master pode mencionar tópicos que serão abordados durante o sprint seguinte, e é tudo. Toda a informação confidencial deve permanecer dentro da equipa.

LIÇÕES DE HISTÓRIA E FESTA DE IDEIAS

Esta Retrospetiva é uma escavação arqueológica que resulta só em listas de “o que é que correu bem” e “o que precisa de ser melhorado”, mas não em ações. Quando a equipa compreender gradualmente o que está a acontecer, a comunicação em si pode melhorar. Mas, como não há discussão sobre como melhorar, a mudança é deixada aos indivíduos em vez de ser planeada para a iteração seguinte.

Os membros da equipa são chamados a nomear ideias, sem discutirem o que aconteceu na última iteração. Tal não funciona porque os problemas deixam de ser claros. As ações podem, assim, não estar ligadas à resolução de problemas e ser apenas sobre experimentar coisas fixes, em vez de tentar resolver o que não está a resultar.

Solução

Uma pessoa, nem mais pessoas nem uma equipa, apenas uma pessoa. Quando toda a equipa está envolvida num item de ação, encontre um voluntário, que não só irá obrigar o cumprimento, mas que também seja o polícia. Se uma pessoa não é responsável, então ninguém é.

Também: Reveja os Itens de Ação. Imprima-os e coloque-os no quadro da equipa. Quando forem cumpridos, risque-os. Reveja a lista na próximaRetrospetiva.

Itens de Acção Pouco Claros são inúteis. O truque é certificar-se que a primeira palavra de um Item de Acção é um verbo. No entanto, este verbo pode ser insuficiente na Retrospetiva. Todos podem perceber o seu significado, mas depois pode não se dar o caso. Quando os Itens de Ação são vistos mais tarde, verifique que se mantém acionáveis.

SEM AVALIAÇÃO DE ITENS DE AÇÃO ANTERIORES

Um erro comum é o fato das equipas não verificarem se o que eles decidiram implementar melhorou a sua situação. As equipas definem tópicos para melhoria para o sprint seguinte, mas pouquíssimas param e analisam se as suas ações resultaram de facto em algum progresso.

Solução

Cada Retrospetiva deve começar com a equipa a avaliar os itens de ação anteriores. O Scrum Master deve guiar a equipa e verificar se os itens anteriores foram cumpridos.

Há algum tempo atrás escrevi um post: “Success Criteria for Retrospectives Topics” em que expliquei um conceito simples. Cada equipa deve chegar a um Critério de Sucesso para anexar a cada problema de progresso, resultante de qualquer retrospetiva. Se as equipas usarem algo como isto, é muito fácil verificar ma próxima Agile Retrospective se o item foi capaz de resolver o problema.

MUITAS VEZES OS ITENS DE AÇÃO SÃO AUTOMATICAMENTE ATRIBUÍDOS AO SCRUM MASTER

É bastante comum que a maioria das equipas veja o Scrum Master como a pessoa a quem atribuir todos os tópicos. Mas, na realidade, o Scrum Master pode não ser a melhor pessoa para resolver o problema.

Solução

Geralmente, os tópicos que resultam das Retrospetiva são muito diferentes. Eu não acredito que uma só pessoa possa resolver todos os problemas. Acredito no trabalho de equipa e que diferentes pessoas devem tomar responsabilidade na abordagem do problema.

Algumas fontes podem dizer que um Scrum Master é quem remove os impedimentos. Honestamente, se ele assume a autoria de tudo, o resultado é uma equipa que depende totalmente no Scrum Master para a resolução de todos os problemas. A melhor abordagem poderia ser escolher pessoas diferentes dentro da equipa para abordar vários tópicos que surgem nas Retrospetivas.

Se tem mais ideias sobre Anti-Padrões de Agile Retrospectives, por favor, partilhe-as comigo. Gostava muito de as adicionar a este post.

Espero que esta publicação tenha mostrado alguns dos meus Agile Retrospectives Antipatterns. Se esta publicação tiver sido útil, partilhe-a com os seus amigos e colegas.

Se considera que as instruções neste blog não são suficientes, por favor, contacte-me. Irei dar-lhe toda a informação. Se quiser consultoria sobre a melhor abordagem, estratégia ou solução para a sua empresa, sinta-se à vontade para entrar em contato comigo.

Nós não fazemos “Agile Consulting”, pois eu acho que isso já está ultrapassado (apesar de usar Agile como base), nós implementamos um produto desenvolvido por mim e a evolution4all durante os últimos 5 anos que o ajuda a atingir “Product Development Excellency”: https://www.organisationalmastery.com se quiser saber mais por favor adicione-me e vamos conversar.

Luis Gonçalves é um empresário, autor e International Keynote Speaker.

Como Executivo Geral da evolution4all ele trabalha Senior Executives para implementar o seu ‘Organisational Mastery’ blueprint. Ele e a sua empresa dão Formação Agile e oferecem Consultoria Agile.