Get best of the week

Antipadrões de retrospectiva na equipe do Agile. Parte 1

Recentemente, calculei que, ao longo de vários anos como Scrum Master, passei mais de 100 retrospectivas em equipes Agile. Quero falar sobre a importância da retrospectiva e como ela reflete a situação na equipe e afeta seu desenvolvimento, neste artigo.



Algumas palavras sobre mim. Desde 2015, concentro-me em formar equipes ágeis felizes e eficazes em empresas internacionais. Além disso, gosto de fazer treinamento interno. Além do trabalho principal com a equipe, ensino Scrum Masters na escola e conduzo treinamentos nas áreas de testes Agile / Scrum / Agile. 

Desde o início da minha carreira como Scrum Master, tive a sorte de trabalhar diretamente com 10 equipes muito diferentes e interessantes. Cada um deles se desenvolveu em um ritmo único e, no entanto, tinha algo em comum - a qualidade das retrospectivas influenciou bastante a eficácia geral da equipe. Ao mesmo tempo, notei que, em qualquer equipe, a retrospectiva, mais cedo ou mais tarde, deixa de funcionar. Algo acontece e essa ferramenta mais popular de inspeção e adaptação é quebrada, ou seja, deixa de ajudar a equipe a se adaptar e melhorar.

Sistematizei minhas observações e gostaria de compartilhar os 5 principais antipadrões que conheci em minhas equipes. 

Dentro de cada antipadrão, quero discutir:

  • sinais e causas de um determinado comportamento;
  • o que fazer Scrum ao Mestre e à equipe para corrigir a situação.

Na primeira parte do artigo, falarei sobre três antipadrões. Na segunda parte, compartilharei observações sobre dois outros antipadrões, bem como minhas recomendações: o que o Scrum Masters e as equipes podem fazer proativamente, ou seja, com antecedência, antes mesmo que o comportamento descrito no artigo apareça, para que a retrospectiva continue funcionando e seja uma ferramenta eficaz para melhorias na equipe.
 

Antipattern No. 1 "Está tudo bem conosco"




A equipe mantém uma retrospectiva, mas considera formalidade. O antipadrão se manifesta no fato de que a equipe, em princípio, decide não realizar uma retrospectiva (sem problemas, está tudo bem - por que ficar juntos?). Mas, na minha prática, esse caso foi extremamente raro e a rejeição da retrospectiva foi ditada por outras razões. Escreverei um artigo separado sobre eles mais tarde. Enquanto isso, voltemos a como reconhecer esse antipadrão.

Sinais e razões:

A equipe reúne, abre o modelo de atividade padrão em retrospecto (louco / triste / contente ou inicia / para / continua), anota os principais momentos positivos da iteração e após 20 a 30 minutos diverge sem discutir problemas e o plano de melhoria na equipe. A equipe evita falar sobre problemas ou convence o Scrum of the Master e o outro de que simplesmente não há lugar para melhorar.
Qual poderia ser a razão para esse comportamento?

  • Os rapazes podem acreditar sinceramente que está tudo bem com eles: entregam o produto, o dono do produto está satisfeito, o que mais é necessário?
  • Essa é uma equipe super-coesa que trabalha em conjunto há muito tempo e não consegue imaginar como você pode se tornar ainda melhor, porque todos na empresa são iguais a eles.
  • Eu conheci equipes cujos membros acreditavam que todos os problemas existentes que estavam na zona de controle ou influência da equipe já haviam sido corrigidos e a equipe ainda não tinha nada a ver com outros problemas, qual era o sentido de perder tempo e discuti-los novamente. Para tais problemas, eu até consegui um termo - "corporativo".

O que fazer:

Nesta história, para mim depende muito de quanto eu, como Scrum Master, acredito que tudo está bem na equipe, ou tenho dúvidas.

Se você sentir que tudo está indo muito bem na equipe, faça o seguinte:

- Oferecer à equipe em retrospecto uma pergunta complexa que sai da zona de conforto. Por exemplo, "o que nós, como equipe, podemos criar para fornecer 10 vezes mais funcionalidade do que agora, ao mesmo tempo". Ou "como você pode se livrar completamente da execução manual da regressão". Para algumas de minhas equipes, a segunda pergunta parecia ainda mais inadequada que a primeira.

A primeira reação a essa pergunta provavelmente será estupor e surpresa, mas o próximo passo pode ser um brainstorming interessante, uma olhada no sistema como um todo e idéias interessantes para otimizar todo o processo de entrega de valor.

- Aproveite a oportunidade para os membros da equipe se conhecerem ainda melhor e bombearem o trabalho em equipe através dos jogos. Não vou me debruçar sobre o tema dos jogos, só posso dizer que existem atividades maravilhosas para trabalhar com os valores do Scrum, para focar em um objetivo comum, para criar confiança em uma equipe. Existem muitos formatos de jogos descritos em fontes abertas. Sobre aqueles que conduzi, compartilho no meu blog profissional Scrum Masters.

Obviamente, os jogos não devem ser completamente substituídos por retrospectivas, mas podem se tornar um "descanso" para a equipe, uma oportunidade de mudar o contexto de trabalho e analisar a eficácia do trabalho em equipe, por outro lado.

E, no entanto, o que fazer Scrum com o Mestre, se não houver essa confiança interior de que está tudo bem? Para este caso, eu tenho duas idéias.

O primeiro é expandir o contexto retrospectivo para a equipe, ou seja, expandir o ângulo de visão da situação na equipe. Por exemplo, isso pode ser alcançado adicionando novos participantes à retrospectiva. Vi muitas equipes que realizavam retrospectivas sem a participação do proprietário do produto devido a várias circunstâncias (ele não queria, tão historicamente, uma barreira do idioma). Para essas equipes, uma retrospectiva com a participação do proprietário do produto ocorrerá de uma maneira completamente nova. A mesma idéia pode ser realizada convidando membros de outras equipes relacionadas que estão à frente ou depois da equipe na cadeia de suprimentos de valor. Um detalhe importante - tudo isso deve ser feito com o consentimento da equipe, o convidado como surpresa provavelmente trará dor e desconfiança ao Scrum Master, do que ajuda a estabelecer uma retrospectiva.

A segunda idéia é oferecer Scrum ao Mestre ou a um dos membros da equipe para coletar dados que eles nunca haviam coletado antes. Eu tenho um exemplo maravilhoso em minha experiência ao analisar as estatísticas coletadas sobre o número de defeitos encontrados dentro do sprint (a saber, a tendência dessa métrica nos últimos 4 sprints) levou a equipe a discussões muito produtivas sobre como melhorar a qualidade dos testes entre os desenvolvedores e como organizar uma interação estreita entre testes e desenvolvimento dentro do sprint. Muitas vezes acontece que, em geral, a equipe lida bem com seus sentimentos e com o feedback externo, mas ainda há muitos pontos a serem aprimorados, basta chamar a atenção da equipe para eles.

Antipattern No. 2 "Noah, nós reclamamos, não há plano"




A história que a equipe chega prontamente à retrospectiva para reclamar, se ressentir, lamentar, reclamar, mas não há um plano para trabalhar com problemas, como um plano de melhoria, como resultado da retrospectiva. Mais precisamente, a equipe tem um plano, um conjunto de ações foi elaborado, há responsáveis, mas esse plano não ajuda a equipe a melhorar, não ajuda a criar experimentos e testar hipóteses para aumentar a eficiência do trabalho ou melhorar a qualidade do produto. Este plano é mais uma formalidade, um plano em prol do plano.

Sinais:

  • A equipe discute vigorosamente o que está acontecendo na equipe, mas não há tempo suficiente para planejá-lo e diverge até a próxima vez, na melhor das hipóteses, com uma lista do que planeja trabalhar algum tempo depois. A questão de exatamente quem, quando e como funcionará permanece em aberto.
  • , , , , : , - , .
  • , , 80-90% – , , , . , , . , ( , , ) , .

Vamos ver como você pode trabalhar com essas situações.

O que fazer:

Vamos começar em ordem. Para que o plano de melhoria apareça na equipe, é necessário que a agenda retrospectiva (todas as suas fases - registro, coleta de idéias, análise de idéias, elaboração de um plano de melhoria, conclusão e feedback) seja transparente para a equipe e haja tempo para isso. elaboração de um plano para novas ações. Tive casos em que não tivemos tempo para elaborar um plano de ação em profundidade e, em seguida, nomeei uma sessão separada para concluir a retrospectiva e formular um plano. Acredito que é melhor expandir o tempo alocado para a retrospectiva do que finalizá-lo no prazo, mas sair sem resultados.

Se houver problemas na equipe para se ajustar ao horário agendado da reunião, existe uma abordagem para definir vários cronômetros, por exemplo, por 15, 8 e 5 minutos. Desde o início, a equipe sabe que a discussão deve terminar no final do terceiro temporizador e está mais focada na negociação. Em geral, as técnicas de facilitação, a organização do trabalho em pequenos grupos e um tempo fixo para discussões e fases individuais do trabalho retrospectivo, fazem maravilhas e ajudam a levar ao desenvolvimento de soluções, mesmo para grupos com dinâmica complexa.

Então, o que Scrum deve fazer com o Mestre se a equipe recuperar questões organizacionais em retrospecto e evitar problemas reais? Existem várias ferramentas que, na minha experiência, ajudaram:

  • – – , , , , « , ».
  • , (, ). , . , , .
  • , , , , , . . , , - .
  • , , , , . , !

№3 « , »




O nome fala por si - um plano foi elaborado para a equipe, mas ações ou experimentos inventados não são realizados.

Sinais: Os

sinais de antipadrão são bastante óbvios - na próxima retrospectiva, a equipe não tem nada para compartilhar como resultados da implementação de ações ou acordos previamente pensados. Todo mundo, é claro, tem boas razões - ele não tinha tempo, suas mãos não alcançavam, ele estava envolvido em assuntos mais importantes, ele esqueceu. Mas, como resultado do progresso em termos de melhorias e experimentos, não.

Falando sobre esse antipadrão, quero insistir em "chamadas perturbadoras" na fase de compilação do plano, que na minha prática eram na maioria das vezes sinais de que as ações do plano não serão executadas:

  • action items (.. ) «, , ». , , .
  • , , . , , « unit ». , , , « », « », , . «, , » .
  • , : «, , , wiki , », « / , , », «, 3 , , , », « , , , »

O que estou fazendo em uma situação em que os planos aparecem na minha equipe que estão escritos, mas não concluídos? Lembro que, se as pessoas não fazem algo, pode haver os seguintes motivos:

1. Eu não entendo
2. Eu não posso
3. Eu não posso
4. Eu não quero

Esse pensamento me ajuda muito a parar e pensar se é possível excluir opções "Não entendo, não sei, não sei como", antes de começar a trabalhar no campo "não quero" e lidar com a motivação da pessoa, por que ele está na equipe e quais são seus objetivos.

O que fazer?

Vamos ver o que exatamente pode ser feito, dependendo do motivo da inação.

Razão 1: um membro da equipe que concordou em executar algum item de ação realmente não entendeu o que era esperado dele.

  • , .
  • , , , , .
  • , , , - . 

Razão 2: um membro da equipe e ficaria feliz em cumprir o item de ação que ele assumiu, mas fisicamente não pode fazer isso, porque ocupado com outras tarefas e ele não tem tempo para isso no sprint.
 
O Scrum Master pode adicionar a atividade mais importante do plano, desde a retrospectiva até o backlog do sprint (depois de concordar com o proprietário do produto no retro ou depois), avaliar, anotar quem fará isso, tornar transparente para todos que a equipe gastará tempo nisso. 

Razão 3: um membro da equipe ficaria feliz em cumprir o que ele se inscreveu, porque ele realmente está interessado e importante (por exemplo, escolhendo a estrutura mais adequada para o teste de estresse), mas ele nunca teve nenhum negócio com isso antes e nunca pode descobrir por onde começar. É aí que ele termina, pois pode ser desagradável explicar à equipe por que ele realizou essa atividade se não sabe como.

O Scrum Master pode verificar com alguém que está pronto para assumir a atividade sob o plano retro, se ele já fez algo assim antes. Caso contrário, com certeza há alguém na equipe com mais experiência nesse assunto que poderia ajudar. E se toda a equipe não possui experiência em campo, o Scrum Master pode assumir a tarefa de procurar especialistas em outras equipes ou na comunidade.

Eu tenho mais uma prática de bônus, o que realmente ajuda a equipe a cumprir o plano - pendure as atividades do plano em um local de destaque para a equipe. Idealmente, cada membro da equipe que realizava algum tipo de atividade tirava um adesivo com este A FAZER para pendurá-lo em um lugar de destaque na área de trabalho e não esquecê-lo. Eles dizem que, se o objetivo está diante dos olhos, uma pessoa consciente e inconscientemente vai para ele. Gosto dessa abordagem muito mais do que lembrar regularmente à equipe que a retro está se aproximando e que vale a pena refrescar em memória do que era o plano da última vez.

Então, compartilhei meus pensamentos sobre os três primeiros antipadrões da retrospectiva em equipes ágeis que conheci em meu consultório, e existem mais dois antipadrões padrão, não menos interessantes e nem menos comuns.

Ficarei feliz em ouvir suas histórias e observações sobre retrospectivas que funcionam e quais não. Conte-nos quais técnicas e técnicas você tem para criar retrospectivas eficazes. Você adivinha quais são os dois antipadrões que pretendo contar na sequência?
 

More articles:


All Articles