Cético em uma equipe Scrum

Minha empresa mudou recentemente para uma maneira ágil de trabalhar e, como parte dela, começamos a usar o SCRUM. Embora eu esteja muito confortável com isso e sinta que esse caminho é superior ao tradicional, alguns de 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. Como exemplo, um dos colegas de equipe está sempre atrasado nas reuniões e realmente não se importa. A IMO de gerenciamento tenta não perceber isso (talvez porque seja novo e leva tempo para as pessoas se acostumarem).

Minha pergunta é: como resolver esse problema sem causar conflitos dentro da equipe?

Quando confrontado com extremo ceticismo, tento algumas coisas:

1.) I demonstrar técnicas como TDD, implantação contínua, programação em par, levantamento de requisitos com os seus usuários, iterações curtas, etc. I não chamam essas técnicas ágeis ou harpa sobre o Agile Manifesto (eu faço harpa sobre Software Artesanato - mas isso é diferente; p). Simplesmente mostro aos membros da equipe ferramentas e técnicas úteis que facilitam suas vidas. Eles tendem a aderir ao movimento ágil quando vêem os benefícios no dia-a-dia.

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

3.) Concordo com os céticos (até certo ponto). Agile 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 podem beneficiá-los imediatamente (um servidor de IC normalmente não é óbvio) e depois testo o resto "Vamos testar os stand-ups por uma semana e depois analisá-los".

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 à sua pergunta. Levante-o com a equipe:

"Eu também sou um pouco cético em relação aos stand-ups, mas acho que, como equipe, devemos tentar por uma semana (sem desculpas!) E depois analisá-lo para ver se funcionou para nós. O que as pessoas fazem?" pensar?"

Um caso típico de Scrum implementado incorretamente .

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

Quando você deseja implementá-lo, deve ter total apoio da equipe e da gerência, ou isso não vai funcionar.

A resistência à mudança é seu inimigo aqui.

Eu sugiro que você comece do zero e apresente o Scrum à equipe e deixe que eles façam perguntas.

Se você não conseguir vender a ideia, não tente forçá-los a usar uma metodologia que eles não desejam. Eles farão de tudo para sabotá-lo. Chegar atrasado nos levantamentos diários é um dos comportamentos que você terá.

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

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 exige muita concentração a longo prazo, como matemática pesada, as reuniões podem prejudicar você e ser frustrante. Eu trabalho com alguém assim, que prefere se encontrar semanalmente, o que é perfeitamente razoável.

Na verdade, para ser sincero, se eu estivesse na sua equipe de programação, provavelmente seria tão cético! Eu já vi uma longa linha de metodologias que deveriam revolucionar as coisas e fazer com que os projetos chegassem dentro do prazo, 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 alguns anos algo novo viria. Não me interpretem mal. Acho que algumas das novas metodologias trazem algumas idéias úteis. Infelizmente, eles também trazem muitos dogmas e idéias estúpidas.

Realmente importa se ele não embarca? Apenas atribua a ele algumas tarefas de programação e deixe-o fazer do jeito que ele quer. Se o trabalho dele é satisfatório, deixe-o. 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, tenho visto muitos bons programadores pararem ou ficarem irritados porque o gerente deles 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 sobre qualquer que seja a moda mais recente.

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

As (melhores) atribuições de escolha são escolhidas primeiro no início da reunião. Quando chegar tarde, dê a ele o que resta para o dia.

Não importa se ele é um presente de Deus para a programação, ele recebe a tarefa ruim que ninguém mais queria. Se ele tentar desenvolver 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 potencialmente compensação. Você pode votar em 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 a gerência daqueles que estão prejudicando a equipe e impedindo que ela seja bem-sucedida.

Lembre-o de que, se ele chegar a tempo, poderá participar do processo.

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

Portanto, a resposta óbvia é que o Scrum Master convoca uma reunião, explica o problema (mas não se engane, todos os membros da equipe já sabem exatamente qual é o problema) e depois lhes 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 mantém a boca fechada.

Obviamente, esta é uma equipe nova para o Scrum. Portanto, a chave é que o Scrum Master tenha que aceitar qualquer resposta que a equipe tenha. Se ele os anula ou impõe suas próprias idéias à solução, ele destrói a confiança que a equipe precisa construir com ele para que eles possam se auto-organizar. É possível que a equipe decida não fazer nada.

De qualquer forma, o problema deve ser analisado na Retrospectiva da Sprint e a eficácia de qualquer solução que eles tenham encontrado pode ser discutida.

Evitar o "conflito de equipe" nem deve ser um fator.

Demita o companheiro de equipe, para que ele não cause polêmica dentro da equipe.

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

A programação é uma atividade de precisão; portanto, um indivíduo raro permaneceria indiferente aos fatos concretos. Pelo menos em teoria.

Quem tomou a decisão de mudar e por quê? Onde aqueles céticos estavam envolvidos com a decisão ou a decisão simplesmente caiu sobre eles?

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

Provavelmente você está pedindo que eles aceitem tudo apenas na palavra dos crentes. Muito provavelmente esses céticos adotaram novas metodologias antes e nenhum benefício foi 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é crie uma pequena competição entre os céticos e seus velhos hábitos e os crentes e seus novos modos.

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

Faça uma reunião de equipe para discutir e descobrir por que sua empresa mudou para o SCRUM e fazer com que todos identifiquem o que pensam sobre o SCRUM agregaria valor ao modo de operação atual. Às vezes, as empresas fazem interrupções complicadas (eu estive em reuniões de scrum onde ninguém realmente escuta e todo mundo fala o que fez ontem e sai. Essas equipes geralmente alcançam um equilíbrio como - "Eu não vou questionar você e você não mexe comigo "e gingar lá. Isso é apenas uma perda de tempo), então leve o que é melhor para você.

Os veteranos geralmente têm muita resistência a qualquer coisa que possa mudar seu estilo de trabalho atual. Portanto, é preciso garantir que haja cenouras suficientes para que eles possam sair de sua 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 paz ou a eliminarão completamente porque não está agregando valor. Ambos são ganha-ganha.