Como a superfície P.O. disfunção em um retro

Eu estou trabalhando com uma equipe que tinha um P.O. que micro gere a equipe, tem uma abordagem muito direcional para trabalhar com a equipe. Muitas vezes, pedindo-lhes "quando as coisas estão acabadas", etc, estou obviamente treinando-o sobre como se comportar como um P.O. e que essa abordagem prejudicará a equipe a longo prazo. Então, isso faz parte do meu papel como Scrum Master é remover esse impedimento para o sucesso das equipes.

No entanto, tenho a oportunidade de fazer um retro sem o P.O. (eles estão fora) e me perguntei se alguém tem alguma abordagem de formato retro que permita que essa disfunção venha à tona da equipe. Então, uma maneira de fazer com que a equipe expresse quaisquer desafios ou preocupações (se houver) com a abordagem do PO? Talvez eles não tenham quaisquer problemas com a sua abordagem, mas seria bom apresentar a opinião deles sobre isso.

3
Esta questão está marcada como scrum , então eu gostaria de receber esclarecimentos no contexto do Guia do Scrum Valores Scrum . 2 valores que devem ser adotados são coragem e respeito: "Os membros do Time Scrum têm coragem de fazer a coisa certa e trabalhar em problemas difíceis" e "Os membros do Time Scrum se respeitam para serem pessoas capazes e independentes". Por que a equipe está aguardando até que a OP não esteja presente para ter essas discussões? Como Scrum Master, o que você está fazendo para treinar o Time Scrum a abordar essas conversas difíceis com coragem e respeito?
adicionado o autor Grant, fonte
O ponto do @Venture2099 é bem aceito, e é por isso que estou recomendando os 5 Porquês . Se ele está microgerenciando, é improvável que seja apenas porque ele gosta disso. Compreender o processo ou a falha de comunicação que está reforçando esse antipadrão é essencial para resolvê-lo!
adicionado o autor Rikalous, fonte
Você perguntou ao Dono do Produto que pressões ele está enfrentando, forçando-o a fazer essas perguntas? Ele tem partes interessadas irracionais para gerenciar? Empatia com o seu papel.
adicionado o autor Venture2099, fonte

3 Respostas

Esperar que o dono do produto esteja ausente antes de iniciar a conversa não é uma boa abordagem do Scrum.

É melhor ter uma discussão aberta em equipe e resolver o problema com todos os presentes.

Se a equipe não falar abertamente na frente do Dono do Produto, então esse é o problema que precisa ser resolvido, não o comportamento do Dono do Produto.

9
adicionado
Acordado. Um pilar do scrum é a transparência. O Scrum Master é responsável por levantar este problema e educar a equipe a seguir a prática do scrum.
adicionado o autor Layna, fonte

Eu não sei em que tipo de cama quente política sua organização pode estar, mas eu evitaria tentar descobrir a opinião das equipes de um membro individual da equipe em um grupo aberto. Acho que pedir por tal coisa colocaria em risco a confiança geral da equipe. Afinal, o que a equipe estaria dizendo sobre mim quando eu estivesse ausente em um filme retrô?

Se você está supondo que o comportamento deste PO está afetando adversamente o desempenho, investigue isso a portas fechadas, onde o anonimato pode ser assegurado. E certifique-se de NÃO fazer perguntas de modo a não confirmar inadvertidamente a sua hipótese de uma forma tendenciosa. Portanto, evite fazer isso em um retro inteiramente e conduza one-offs em particular.

3
adicionado
Eu concordo principalmente com o seu post, especialmente sobre o viés de confirmação que impede uma análise eficaz de causa raiz. Tenho menos certeza sobre o conselho para manter a conversa a portas fechadas. Há momentos em que isso é útil e momentos em que isso é contraproducente e não no espírito das comunicações abertas da equipe. Eu quero te dar 4/5s de um upvote, mas o sistema não me deixa. :)
adicionado o autor Rikalous, fonte
Você está certo, David. Eu estava tendo uma visão mais ampla, mas quando você coloca dessa forma (ocasionalmente sinto falta do alvo próximo de Too Narrow), seu conselho é sólido. Eu aprecio o esclarecimento, e por este meio ofereço um +1.
adicionado o autor Rikalous, fonte
@ ToddA.Jacobs, eu concordo com as comunicações abertas, mas o OP escreveu alguns itens que tornaram um fórum aberto contra-indicado. 1) ele tem uma hipótese não verificada; 2) o PO já está sendo "treinado", o que sinaliza um problema pessoal; 3) todo o artigo tem alguns sinais de uma maturidade de equipe que não é a melhor, e é improvável que a utilização de táticas maduras em uma equipe imatura funcione. O maior impulsionador é que parece um grupo pronto para acontecer em um possível problema pessoal. Isso, para mim, requer discrição.
adicionado o autor Jarin Udom, fonte

Visão geral

Barnaby Golden, Thomas Owens, and David Espina have all given good answers, but I want to address your core question in a different way. You ask:

Gostaria de saber se alguém tem alguma abordagem de formato retro que permita que essa disfunção venha à tona da equipe.

Como o Scrum Master, é sua responsabilidade de facilitar discussões respeitosas, corajosas e às vezes difíceis dentro da retrospectiva. Acordos de trabalho em equipe, papéis e responsabilidades, e comunicação da equipe são todos tópicos que estão bem dentro do mandato de uma retrospectiva típica, mas é seu trabalho garantir que isso seja feito de maneira construtiva.

Percebo que você está procurando um formato simples para abordar o tópico e, embora eu forneça um abaixo, sinto que esse aspecto de sua pergunta é, na verdade, parte do problema. O teor geral do seu post original já implica um forte julgamento sobre a situação e os participantes, e isso não é propício para manter uma retrospectiva saudável, porque estabelece uma dinâmica Team-vs-PO que é provável para se dedicar à defesa e apontar os dedos.

Em vez disso, se as pessoas estiverem levantando a questão com você em seu papel como Scrum Master ou Membro da equipe, então, como membro da equipe, você tem o direito de mencionar os problemas que foram trazidos à sua atenção dentro da retrospectiva. Depois, certifique-se de facilitar a discussão para mantê-la nos trilhos e de ser construtiva e manter a equipe concentrada em seguir adiante com um plano ou ação concreta.

Um exemplo trabalhado

O objetivo do Scrum Master não é atribuir culpa; é facilitar a melhoria contínua do processo. Com isso em mente, um Scrum Master experiente pode usar o seguinte formato para descobrir, tratar e resolver um problema de processo baseado em função ou comunicação dentro de uma Retrospectiva da Sprint.

Mini-Script do Scrum Master

     

Neste Sprint, várias pessoas levantaram preocupações sobre o relatório de status para o Dono do Produto, reduzindo a produtividade da Equipe de Desenvolvimento medida por ... Para resolver essas preocupações, gostaria que todos nós examinássemos:

     
      
  1. Se é realmente um problema para a equipe como um todo ou para membros individuais.
  2.   
  3. Em caso afirmativo, o que há de errado com nosso processo, comunicações ou transparência que está acionando esses fatores que, para eles, são atraídos por status excessivo?
  4.   
  5. Agora que identificamos o problema, quais são os nossos itens de ação como uma equipe?
  6.   

Você também pode usar técnicas como 5 Whys para identificar uma causa raiz e garantir que você intervenha com firmeza para evitar ad hominems ou qualquer tentativa de atribuir más intenções ao invés de descobrir uma razão. Lembre-se de que o objetivo é identificar problemas em processo e, em seguida, identificar soluções orientadas a processos.

Ok, então o que?

Como outro exemplo prático, parece provável que, neste caso, os 5 Porquês possam identificar uma falta de confiança do Dono do Produto na capacidade da Equipe de Desenvolvimento de atingir a Meta da Sprint ou descobrir um processo de desenvolvimento menos transparente que o Backlog da Sprint. O Kanban Board, ou outros radiadores de informação, não são confiáveis ​​ou não estão sendo usados ​​com o melhor efeito. Seja qual for o problema, pense nele como um problema de processo e encontre uma solução orientada para o processo como uma equipe que toda a equipe possa obter.

Adaptar os acordos de trabalho e as práticas da equipe para resolver problemas do processo está no cerne do Scrum, do Kanban e do Manifesto Ágil. Os papéis, cerimônias e processos que formam o Scrum servem para facilitar a negociação efetiva de acordos de trabalho sustentáveis ​​e não para culpar. Sempre certifique-se de que toda a equipe (e especialmente o Scrum Master) mantenha um foco implacável nos problemas do processo, e não em encontrar falhas individuais!

2
adicionado
Quando eu tive essa situação, os Devs não falaram porque o PO era um executivo sênior e poderia ficar 'assustador'. Mas eles obviamente não estavam felizes, então eu escolhi lidar com isso pessoalmente com o PO. Como os Devs esperavam, a conversa ficou bastante "robusta". Embora isso tenha finalmente permitido um acordo melhor com o PO, sua resposta me faz desejar que eu possa voltar a pelo menos tentar obter um acordo de equipe da maneira que você sugere. Como você diz, evitar uma dinâmica entre equipe e PO é vital. Desde então aprendi que 'evitar conflitos' é uma das cinco disfunções de uma equipe. Excelente resposta.
adicionado o autor onedaywhen, fonte