Skeptic em um Time Scrum

14

Minha empresa mudou recentemente para uma maneira ágil de trabalhar e, como parte disso, começamos a usar o SCRUM. Enquanto estou muito confortável com isso e sinto que este caminho é superior ao tradicional, alguns dos meus colegas de equipe não compartilham a mesma opinião. Na verdade, eles são muito céticos sobre "todas essas coisas ágeis" e não levam isso a sério. Por exemplo, um dos colegas de equipe está sempre atrasado nas reuniões e não se importa com isso. O IMO de gerenciamento tenta não notar isso (talvez porque seja novo, e leva tempo para as pessoas se acostumarem a ele).

Minha pergunta é: como lidar com esse problema sem criar um conflito dentro da equipe?

    
por Sorantis 10.01.2011 / 12:28
fonte

10 respostas

21

Quando me deparo com um extremo cepticismo, tento algumas coisas:

1.) Demonstro técnicas como TDD, Implantação Contínua, Programação de Pares, Coleta de Requisitos com seus usuários, iterações curtas, etc. Eu não chamo essas técnicas Agile ou harpa sobre o Agile Manifesto (eu faço harpa sobre Software Craftsmanship - mas isso é diferente; p). Eu simplesmente mostro aos membros da equipe ferramentas e técnicas úteis que tornam suas vidas mais fáceis. Eles tendem a pular na onda Ágil quando vêem os benefícios no dia-a-dia.

2.) Eu não troco imediatamente para uma completa metodologia SCRUM (ou outra). É sempre melhor introduzir pequenos aspectos do Agile de cada vez.

3.) Eu concordo com os céticos (até certo ponto). Ágil não é uma bala de prata e SCRUM, Kanban, Lean etc também não são uma bala de prata. Em vez disso, eu trabalho com eles para ver quais aspectos poderiam beneficiá-los imediatamente (um servidor de IC geralmente é óbvio) e depois testo o resto. "Vamos dar uma pausa por uma semana e depois revisá-la".

Como qualquer metodologia, o SCRUM e outros precisam realmente trabalhar com a equipe e a organização, não aliená-los.

Então, para ir diretamente para sua pergunta. Levante-o com a equipe:

"Eu também sou um pouco cético sobre os stand-ups, mas acho que como equipe devemos dar uma boa chance por 1 semana (sem desculpas!) e depois analisá-la para ver se funcionou para nós. O que as pessoas pensam? "

    
por 10.01.2011 / 12:42
fonte
16

Um caso típico de Scrum implementado incorretamente.

Scrum foi imposto à equipe. A equipe (inteira) não escolheu.

Quando você quiser implementá-lo, você deve ter total apoio da equipe e do gerenciamento, ou não funcionará.

Resistance to change is your enemy here.

Eu sugiro que você comece de novo e apresente Scrum para a equipe e deixe-os fazer perguntas.

Se você não vender a ideia, não tente forçá-la usando uma metodologia que não deseja. Eles farão de tudo para sabotá-lo. Chegar atrasado em stand ups diários é um dos comportamentos que você terá.

Por favor, note que o Scrum pode não ser aconselhável para a sua empresa. As únicas pessoas que podem responder a essa pergunta são as pessoas que trabalham na base. A equipe .

    
por 10.01.2011 / 13:30
fonte
5

Pode ser que o conceito de reuniões diárias não se aplique muito bem ao que uma pessoa está fazendo. Essas reuniões não são gratuitas.

Se o que você está fazendo requer muita concentração a longo prazo, como matemática pesada, as reuniões podem desestabilizá-lo e ser frustrante. Eu trabalho com alguém assim, que prefere se reunir semanalmente, o que é perfeitamente razoável.

    
por 10.01.2011 / 15:48
fonte
5

Na verdade, para ser honesto se eu estivesse na sua equipe de programação, eu provavelmente seria tão cético! Eu vi uma longa linha de metodologias que deveriam revolucionar as coisas e fazer projetos chegarem no prazo, dentro do orçamento e sem erros. Este é apenas o mais recente. Por que eu deveria acreditar no óleo de cobra? 10 anos atrás as mesmas pessoas estavam açoitando outra coisa, em poucos anos algo novo surgirá. Não me entenda mal, acho que algumas das novas metodologias trazem algumas ideias úteis. Infelizmente, eles também trazem muitos dogmas e ideias idiotas.

Será que realmente importa se ele não embarca? Basta atribuir-lhe algumas tarefas de programação e deixá-lo fazer do jeito que ele quer. Se seu trabalho é satisfatório, deixe-o ser. Se o trabalho dele não for satisfatório, substitua-o. Por que é tão importante que as pessoas sigam o scrum?

Ao longo dos anos, vi muitos bons programadores desistirem ou ficarem irritados porque seu gerente continua introduzindo novas metodologias. Eles só querem codificar e fazer o trabalho. Confie em mim daqui a alguns anos, você estará amaldiçoando o scrum e pulando em qualquer que seja a última moda passageira.

    
por 19.05.2011 / 06:03
fonte
1

Se você está agilizando, então você deve ter um backlog do qual você está trabalhando. Use o scrum para distribuir atribuições do backlog.

A escolha (melhor) das tarefas é escolhida primeiro no início da reunião. Quando você chega atrasado apenas dar-lhe o que resta para o dia.

Não importa se ele é um presente de Deus para a programação, ele recebe a tarefa de baixa qualidade que ninguém mais queria. Se ele tentar empatar outra tarefa ou trabalhar em outra coisa, a equipe como um todo precisa se apoiar nele e forçá-lo a trabalhar apenas em sua tarefa "escolhida". Você provavelmente deve ter um mestre de construção que possa rejeitar suas alterações se ele não estiver trabalhando no trabalho escolhido.

Além disso, a equipe deve estabelecer metas e possíveis compensações. Você pode votar como uma equipe para não recompensar aqueles que não estão participando. Isso varia de acordo com a quantidade de propriedade que seu gerenciamento deu à sua equipe ágil. Lembre o gerenciamento daqueles que estão prejudicando a equipe e impedindo o sucesso da equipe.

Lembre-o de que, se ele aparecer na hora, ele poderá participar do processo.

    
por 10.01.2011 / 17:57
fonte
1

As equipes de scrum devem ser auto-organizadas. O Scrum também trabalha implementando extrema transparência em tudo.

Então a resposta óbvia é que o Scrum Master chama uma reunião, explica o problema (mas não se engane, todos da equipe já sabem exatamente qual é o problema) e então diz que eles têm 1 hora para descobrir o que eles vão fazer sobre isso. Então ele se senta no canto e fica de boca fechada.

Obviamente, esta é uma equipe nova no Scrum. Então, a chave é que o Scrum Master tem que aceitar qualquer resposta que a equipe apresentar. Se ele os anular, ou impor suas próprias idéias à solução, destruirá a confiança que a equipe precisa para construir com ele, permitindo que eles se auto-organizem. É possível que a equipe decida não fazer nada.

Em qualquer caso, o problema deve ser analisado na Retrospectiva da Sprint e a eficácia de qualquer solução que venha a surgir pode ser discutida.

Evitar o "conflito de equipe" não deve ser um fator.

    
por 19.05.2011 / 05:12
fonte
0

Demita o colega de equipe, então ele não estará causando controvérsia dentro da equipe.

    
por 10.01.2011 / 12:31
fonte
0

Navegue pelo seu trabalho antigo, descubra vários exemplos de como a abordagem de queda de água o decepcionou muitas vezes no passado. Em seguida, apresente os casos ao seu companheiro de equipe. Com um vislumbre do bom senso, ele verá a luz.

A programação é uma atividade de precisão para que um indivíduo raro não seja receptivo aos fatos concretos. Pelo menos, em teoria.

    
por 10.01.2011 / 12:35
fonte
0

Quem tomou a decisão de mudar e por quê? Onde aqueles céticos sobre a decisão em tudo ou foi a decisão apenas caiu sobre eles?

Você está sendo muito rígido e / ou rápido na implementação de seus novos métodos? Você colocou produtos bons (não necessariamente perfeitos) usando seus métodos antigos? Você já demonstrou aos céticos como isso os beneficiará? Você pode demonstrar isso? Será que aqueles que "viram a luz" demonstraram aos céticos como isso os beneficia, à equipe e à empresa?

Provavelmente você está pedindo a eles que aceitem tudo apenas na palavra dos crentes. É mais do que provável que esses céticos tenham adotado novas metodologias antes e nenhum benefício jamais realizado.

Talvez você possa fazer um projeto ou dois com apenas os crentes trabalhando nele usando seus novos procedimentos. Faça medições reais e demonstre aos céticos benefícios reais. Talvez até mesmo estabeleça uma pequena competição entre os céticos e seus velhos modos e os crentes e seus novos caminhos.

Claro, então o que você faz se os céticos vencerem?

    
por 10.01.2011 / 16:06
fonte
0

Faça uma reunião de equipe para discutir e descobrir por que a sua empresa mudou para o SCRUM e fazer com que todos identifiquem o que pensam sobre o SCRUM. Isso agregaria valor ao modo de operação atual. Às vezes, as empresas fazem interruptores de cabeça torta (eu tenho participado de reuniões onde ninguém realmente ouve e todo mundo simplesmente recita o que eles fizeram ontem e sai. Essas equipes geralmente alcançam um equilíbrio como - "Eu não vou questionar você e você não estraga comigo "e waddle lá. Isso é apenas uma perda de tempo), Então, tome o que é melhor para você.

Os veteranos geralmente têm muita resistência a qualquer coisa que possa mudar seu estilo atual de trabalho. Portanto, você precisa garantir que haja cenouras suficientes para que eles possam sair da inércia. Nesse caso, eu teria 1: 1 com essa pessoa ou faria dele o scrum master :). Uma vez que você lhes dê responsabilidade, eles encontrarão a paz ou eliminarão completamente porque não está agregando valor. Ambos são win win.

    
por 19.05.2011 / 06:31
fonte

Tags