Membros da equipe dominante em uma equipe Scrum

O que você faria em uma situação em que um membro da equipe tenta assumir responsabilidades não é inicialmente atribuído a ele, mas ao Scrum Master?

A equipe Scrum é auto-organizada, para que haja espaço para alguém um pouco mais dominante. Outros devem pedir a ele suas idéias sobre as tarefas em que estão trabalhando, mas seu domínio deve ser mantido sob controle.

O que você pode fazer:

• Motive os outros a serem independentes, mas colaborativos - isso pode ser melhor alcançado se você cooperar com o gerente e o RH que lhes definirá algumas expectativas, que serão avaliadas regularmente.
• Durante stand-ups, planejamento e retrospectivas; deixe que outros membros da equipe falem primeiro. Durante as revisões, permita que outros membros da equipe apresentem histórias de usuários que eles implementaram.
• Deixe que os outros escolham as tarefas primeiro, para que o desenvolvedor dominante não possa apenas escolher as tarefas que deseja executar.
• Envolva a programação de pares para algumas tarefas, para que o membro dominante da equipe esteja colaborando com outros desenvolvedores.
• Seja democrático - a opinião de um membro da equipe não é suficiente para fazer alterações no processo - o Scrum só funcionará se a equipe se comunicar com clareza ou você estiver apenas bloqueando o outro.
• Se nada disso ajudar, você deve falar com o membro dominante da equipe e explicar a situação para ele - mas cuidado, não há líder de equipe no Scrum por um motivo. Se você tiver o apoio da gerência, também poderá ameaçar a estabilidade no emprego, mas essa deve ser a última opção.

Se o membro da equipe dominante não quiser perder seu domínio e os membros passivos da equipe não quiserem ser mais ativos, você precisará do apoio do gerente e do RH. Isso pode ser um problema se o processo Scrum não for incentivado pela gerência.

Presumivelmente, a razão para esta pergunta é porque você sente que a equipe está, de alguma forma, com baixo desempenho devido a essa pessoa dominante. Talvez porque o resto da equipe não esteja contribuindo 100% porque, bem, qual é o objetivo?

Como gerente, se você for, é sua responsabilidade garantir que todos os seus funcionários entendam quais são suas funções. Especificamente, o que se espera deles e como serão avaliados. Como membro de uma equipe de Scrum, cada pessoa é pessoalmente responsável pelo sucesso da equipe. Portanto, esse membro da equipe dominante precisa saber que está falhando nessa responsabilidade e será avaliado de acordo.

O feedback é um ponto chave. Se houver uma reunião de equipe e essa pessoa dominar a discussão, forçar seus projetos e abordagens para o restante da equipe e empurrar o restante para papéis passivos, ele precisará ser informado, sem rodeios e em particular, que ele não está cumprindo os requisitos do papel. Se você vê-lo destacando sorrateiramente apenas suas próprias realizações pessoais, ele precisa ser chamado e compreender que as realizações pessoais são muito valorizadas, muito menos do que ajudar a equipe a ter uma conquista em grupo.

Tudo isso é difícil, mas é para isso que servem os gerentes e o Scrum Masters.

Há uma outra maneira possível de fazer isso. Faça disso um problema de equipe. Convoque-os e diga-lhes que eles estão mal conseguindo e aqui está o porquê. Peça-lhes para encontrar uma solução. Você pode se surpreender.

Por que não perguntar ao desenvolvedor alfa sua opinião. É perfeitamente possível que ele não tenha idéia do efeito que está tendo. Leve-o de lado e diga o que você pensa. Você pode até discutir a questão de "ei, você é nosso desenvolvedor líder, mas precisamos elevar essas pessoas ao seu nível, preciso de sua ajuda para descobrir como podemos fazer isso?". Transforme seu domínio em um ativo. Veja se ele pode ver maneiras de fazer isso.

Se ele mediu o quão bem ele apoia sua equipe e os eleva a seu nível, ele terá mais motivação para fazer exatamente isso.

Você quer dizer que ele não está trabalhando no interesse da equipe (eu acho), ou seja, ele é mau de alguma forma, então sim, remova-o. Mas um homem sábio me disse uma vez: não assuma má vontade, quando a incompetência ou a simples ignorância forem mais prováveis.

Parece que ele tenta ser o Scrum Master.

Esclareça suas posições e aja de acordo.

O papel do Scrum Master é permitir o espírito de equipe. Se você não conseguir fazer dessa única pessoa um jogador de equipe, remova-a da equipe .

Nota rápida: seu desenvolvedor dominante não é mais problemático que seu desenvolvedor passivo.

atualmente o planejamento de sprint é uma função que gira em toda a equipe

O planejamento da sprint deve envolver toda a equipe, não ser entregue a uma pessoa de cada vez. A menos que haja uma boa razão para isso, vejo isso como um problema grave.

Se o que você está dizendo é verdadeiro e objetivo, você tem um grande problema em suas mãos: pessoas que não participam e o "Dominador" que impede um processo verdadeiramente ágil. Como mestre do srum, cabe a você agir. Talvez você queira confiar em seu gerente de projeto sobre essa situação.

Muitas equipes se afastam do núcleo do ágil e é seu trabalho trazê-las de volta. Você precisa ensinar e reinserir valores ágeis na equipe. De fato, você deve estar constantemente ensinando valores ágeis. Mantenha sua visão de agilidade, deixe-a clara e poderosa. Mostre a eles seu compromisso com "o ágil bem-sucedido".

Para fazer isso, conduza-os pelos valores do manifesto ágil e do Scrum. Pergunte a eles o que significa colaboração para eles e por que é importante. Pergunte a eles sobre o papel da confiança no ágil. Este é um ótimo momento para discutir por que não há função de líder de equipe nem gerente de projeto no Scrum e que é responsabilidade de toda a equipe criar um ótimo software, não o indivíduo.

Planeje uma sessão retrospectiva inteira sobre isso. Faça com que eles se comprometam com alguns valores e acompanhem durante a próxima retrospectiva. Não aponte os dedos, use métodos neutros.

Introduzir métodos que force os outros membros a expressarem suas opiniões com segurança. Algo simples como um punho de cinco é ótimo para ouvir as vozes silenciosas da equipe. Isso torna dolorosamente óbvio que a equipe discorda do cara dominante. O Planning Poker funciona bem, mas a chave é não permitir discussões antes que as cartas sejam mostradas. Qualquer coisa que ajude a fazer com que os outros sejam ouvidos sem iniciar conflitos é útil.

Se tudo correr bem, está tudo pronto. Caso contrário, converse com ele sobre o problema. Use o coaching e faça perguntas poderosas que podem ajudá-lo a entender o problema claramente. Tente chegar à raiz do motivo pelo qual ele assumiu o papel dominante. Talvez ele não tenha confiança na equipe (por quê?) E talvez ele sinta que é responsável pelo sucesso (por quê?). Eu suspeito que esse papel não é algo que ele deseja e é bem possível que ele queira que ele mude. Ele pode dar a volta e perceber isso.

Talvez o desenvolvedor "dominante" seja recompensado por seu desempenho individual e não pelas conquistas da equipe?

No passado, assegurei-me de que pessoas muito vocais e com idéias claras também sejam recompensadas (por meio de seus objetivos), promovendo contribuições de outras pessoas.

Em geral, acho uma má idéia recompensar os membros do scrum solidamente por sua contribuição individual e não pelas conquistas da equipe.

Você também pode tentar fazer uma rodada de feedback de 360 ​​na sua equipe para todos os membros da equipe, apenas se achar que os outros membros da equipe serão sinceros nos comentários.

Propor que ele se torne o Scrum Master para o sprint a seguir.

Pessoas dispostas a assumir responsabilidades não são um problema (desde que não desejem monopólio sobre elas), é precisamente o que estamos buscando alcançar com a auto-organização.

Equipes com um papel de mestre de scrum rotativo não são incomuns, a propósito.

A única tarefa do mestre Scrum é garantir que todos sigam as regras do livro Scrum. Se os mestres que não são do Scrum fizessem isso sozinhos, sem a interferência do mestre do Scrum, isso apenas mostraria que você está em ótima forma (Scrum)! Quanto menos o mestre Scrum tiver que fazer, mais fraca e mais enxuta sua equipe será da perspectiva do Scrum. Eventualmente, o papel do Scrum master pode / deve ser eliminado, ele está lá para você começar e ensinar Scrum.

Novamente, o Scrum master não participa do processo de desenvolvimento. Ele deve garantir que todas as partes interessadas se comuniquem a tempo sobre as coisas certas, ele conhece o Scrum e fornece orientação para o Scrum, ele não é proprietário de produto ou líder de projeto. Se você experimentar algo diferente, pode não estar fazendo Scrum com espírito ágil. Obviamente, em ambientes menores, o Scrum master pode ser um papel que um dos membros da equipe ou partes interessadas desempenha ao lado. Então é apenas um limite que se coloca quando é hora de formalidades. Não confunda isso com um papel de liderança, é um papel de orientação.

Abrace o individualismo e o desempenho individual, mas também tente capacitar os indivíduos passivos a se tornarem mais participativos.

Minha experiência diz que, embora possam parecer semelhantes à primeira vista, comunismo e agilidade não são os mesmos. O Agile não visa uma sociedade sem classe (equipe), mas um software que funcione.

Tente fazer com que seu desenvolvedor alfa entenda que ele pode ajudá-lo a desenvolver as habilidades de outras pessoas pedindo e treinando, em vez de responder sempre primeiro e obtendo realizações individuais. Certamente seu desenvolvedor alfa é aquele que se preocupa com um bom software, e isso é algo que você não pode se permitir perder.