Alguns membros da equipe não participam ativamente do planejamento da Sprint

15

Alguns membros da equipe apenas esperam até que as histórias com maior probabilidade de serem discutidas sejam discutidas e só então eles participam. Caso contrário, eles apenas brincam com o telefone e não ouvem.

De alguma forma, eu entendo essa posição. Por que ouvir uma discussão sobre um recurso que é improvável que você ajude a desenvolver no Sprint ou nunca?

O que você acha que devemos fazer?

agile scrum

— Eugene
fonte

9

Qual é o tamanho dessa equipe?

— 10134 JeffO

8

O @JeffO acertou em cheio na cabeça - esse é um problema clássico da equipe de grandes dimensões. Equipe sobredimensionada = autoridade / responsabilidades individuais subdimensionadas = envolvimento individual subdimensionado. Uma equipe de tamanho certo significa que tudo o que vocês falam afeta todos na sala. Como alternativa, você está exagerando nas responsabilidades - por que ouvir uma discussão sobre um recurso que provavelmente não ajudará? Uma equipe de tamanho certo, que não possui responsabilidades em silos, deve permitir que todos trabalhem em todos os recursos.

— Jimmy Hoffa

7

Telefones desativados, sem exceções. Reunião simples senso comum.

— user1019696

5

@ user1019696 para ser justo, eu poderia receber um telefonema da minha esposa que meu filho quebrou a perna a qualquer momento. Há uma grande diferença entre "desligar o telefone" e "não mexer com o telefone no meio de uma reunião, porque é simplesmente desrespeitoso".

— Jimmy Hoffa

4

@ Quando você fala de uma época em que havia secretários de empresas, não havia essa pessoa em uma empresa em que trabalhava há anos - eles não tinham nada para fazer. E não, não pode esperar. Especialmente não no trabalho, desculpe, mas trabalho em família. Dito isto, talvez eu receba uma ligação no meio de 1 em 30 ou 40 reuniões (talvez ??), das quais provavelmente respondo 1 em 30 ou 40 ... Não é difícil não ser um idiota com seu telefone. Se as pessoas precisam delas desativadas ou removidas de suas pessoas para evitar serem idiotas, talvez essa pessoa seja apenas uma idiota.

— Jimmy Hoffa

32

Interrompa a propriedade do código. Torne igualmente provável que qualquer pessoa em uma equipe trabalhe em uma determinada tarefa.

Certamente haverá alguma reação a esse fato, porque os desenvolvedores se sentem confortáveis com uma área específica do código e com outras pessoas que não olham por cima dos ombros. Além disso, a gerência verá um problema com o trabalho demorando mais do que normalmente, porque sempre há uma curva de aprendizado.

Mas é realmente no melhor interesse de todos. Ser indispensável é uma espada de dois gumes. Começa a ficar mais difícil tirar folgas à noite, nos fins de semana ou tirar férias. E a propriedade do código é ruim para uma empresa porque, quando alguém sai, custa mais tempo do que você já economizou em pequenos pedaços de transferência de conhecimento.

— pdr
fonte

4

+1 Absolutamente. Há uma falsa impressão de eficiência quando você acha que os codificadores são apenas mais uma parte da linha de montagem e depois se pergunta por que um projeto é atrasado porque uma das engrenagens precisa ser substituída.

— 10134 JeffO

3

@JeffO que é muito bonito o padrão entre a gestão da empresa de desenvolvimento de software na minha experiência, considerando que os desenvolvedores sejam peças idênticas em uma máquina que pode ser imediatamente trocada por outra unidade de carbono ...

— jwenting

3

@jwenting, o que os torna perfeitamente adequados para serem terceirizados também. Não vejo por que os desenvolvedores ajudam nessa atitude.

— GrandmasterB

1

@jwenting Esse é o ponto do ágil. Para mudar esse tipo de visão sobre as coisas.

— eufórico

1

@Euphoric na minha experiência o resultado final é o inverso, os gerentes de ver as pessoas ainda mais como ativos que podem ser apenas trocados na mosca, como requisitos ...

— jwenting

15

Você convida as pessoas certas para suas reuniões? Se você dividiu o sistema em áreas de responsabilidade das subequipes, por que convidar todas as subequipes para todas as reuniões?
Por exemplo, se você possui uma equipe de front-end e uma equipe de back-end, mantenha as sessões de planejamento do trabalho de front-end para os membros da equipe de front-end. Talvez convide alguém da equipe de back-end como contato, caso uma tarefa ultrapasse os limites da equipe (mas, se isso acontecer com freqüência, convém reavaliar a divisão de responsabilidades entre as equipes).
Idealmente, todos deveriam trabalhar em tudo, mas na realidade isso geralmente não é prático, a menos que seu sistema seja realmente pequeno e simples, resultando em todos conhecendo cada parte dele minuciosamente. Na prática, é claro que muitos sistemas são grandes o suficiente para esperar que todos os membros de sua organização tenham conhecimento suficiente de uma tarefa planejada para poder fornecer informações válidas durante as sessões de planejamento (e muito menos ser igualmente produtivo trabalhando em todas as partes do sistema). apenas não é realista.

— jwenting
fonte

12

O desinteresse deles é apenas um sintoma. O problema é que você não está distribuindo o trabalho uniformemente para todos os membros da sua equipe. Idealmente, cada membro da equipe deve pegar qualquer novo ticket não restrito a determinadas áreas do projeto.

— Tom Squires
fonte

3

Isso é legal em teoria. Na prática, especialmente em projetos grandes, o sistema pode ser grande o suficiente para que seja impraticável que cada membro da equipe tenha conhecimento suficiente de cada parte dele para ser produtivo ao trabalhar nele.

— jwenting

@jwenting - parece que essa equipe tem muita certeza de que nunca precisará trabalhar em outras partes. Embora uma pessoa não saiba tudo, isso não significa que ela deva aprender o mínimo possível.

— 10134 JeffO

@JeffO verdade, mas não se pode esperar que eles participem ativamente do planejamento de coisas para áreas das quais não têm conhecimento. Ouça e aprenda, mas mantenha a boca fechada. E talvez usar seu celular para fazer algumas fotos do conselho de planejamento :)

— jwenting

1

@jwenting na prática em grandes projetos, você precisa distribuir mais o trabalho! Não é que todos tenham o mesmo conhecimento, mas é igualmente provável que trabalhem em qualquer área específica. Permitir desculpas aumenta a probabilidade de os membros da equipe não adotarem novas áreas.

— Dave Hillier

5

Parece um problema motivacional - por que algumas pessoas não se importam com o projeto em que estão trabalhando? Talvez seja porque a equipe está dividida entre os 'organizadores' e os 'excluídos'.

Portanto, envolva todos, em vez de 1 ou 2 pessoas encarregadas das sessões de planejamento, você envolve todos - faça com que pessoas diferentes se encarregem de cada sessão, de preferência faça com que pessoas diferentes se encarregem durante a sessão. Gire tudo ao redor. Eu sei que isso pode parecer difícil, porque sempre há alguém que quer se preocupar e organizar todos, mas o problema é aqui.

Aqui está uma idéia: ao planejar, escolha uma pessoa aleatoriamente para cuidar de cada história. Aleatoriamente. Registre também quem foi o responsável pelo planejamento, para que, no próximo sprint, você saiba se eles fizeram um bom trabalho ao obter um bom consenso de estimativas e divisão de tarefas. Isso fará com que prestem atenção e também lhes dê um motivo para se envolver com o projeto.

Lembre-se de que o problema não é deles, é você e a maneira como as sessões de planejamento são realizadas. Portanto, quando alguém assume um plano de história, escolhe como proceder, deve haver uma maneira oficial de proceder. (ou seja, não se sente e continue a forçar sua organização por procuração)

— gbjbaanb
fonte

Boas idéias. Espero que as pessoas não vejam isso como perda de tempo.

— Eugene

1

Qual é a duração do seu sprint?

Durações de sprint mais longas levam a

Mais trabalho a ser planejado no sprint, o que leva a
Reuniões de planejamento mais longas, o que leva a
Maior dificuldade para os membros da equipe se manterem focados, ...
Os membros da equipe ficam entediados

Portanto, se a duração do seu sprint for superior a duas semanas, tente trabalhar em sprints mais curtos.

Se for difícil fazer com que as partes interessadas se comprometam com sprints mais curtos, você pode pular algumas das reuniões formais, por exemplo, fazer a revisão do sprint após cada 2 sprints, em vez de após cada sprint.

— Pete
fonte