Como faço para lidar com uma equipe de scrum contraproducente?

Histórico:
Eu tenho trabalhado como parte dessa equipe nos últimos três anos e, nesse período, tivemos três Scrum Master diferentes, que executaram as coisas de maneira diferente.

Devido a essa mudança no Scrum Masters e a maneira como eles administram o programa, deixou minha equipe entorpecida com a ideia do Scrum, porque os princípios não foram aplicados de maneira consistente e um dos Scrum Masters era uma pessoa que não acredita em agilidade. desenvolvimento e apenas manteve eventos e artefatos como um novato para cumprir as decisões da empresa.

Agora, os membros da minha equipe ficam aborrecidos e entediados quando realizamos eventos do Scrum e uma pessoa em particular é muito verbal sobre isso.

Presente:
Há dois meses, a empresa me nomeou Scrum Master da minha equipe por causa de minha dedicação ao trabalho ágil e seus princípios.

Estou sofrendo muito com a pressão atmosférica da falta de vontade dos membros da minha equipe em fazer o Scrum.

Como mencionado, eles estão aborrecidos com todo o processo, o que dificulta muito para mim porque eles não estão se engajando nas conversas necessárias para tornar eficaz o Planejamento, Retrospectiva e Daily Scrum.

Para eles, o planejamento é apenas uma perda de tempo, porque acabamos de transbordar para o novo Sprint e não concluímos o trabalho de qualquer maneira, então, por que se preocupar?

Durante a Retrospectiva, sinto que eles querem dizer "Pare de fazer Scrum". Uma pessoa faz, mas as outras ficam em silêncio e eu tenho que lidar com isso toda vez.

O Daily Scrum é novamente apenas uma perda de tempo para eles, porque nenhum deles se incomoda em conversar e planejar o dia. Eles apenas declaram: "Eu trabalhei na tarefa X ontem e vou trabalhar nisso novamente hoje". E na maioria das vezes eles brincam até eu ficar mais severo.

Eu tenho sido muito grande quando se trata de como eles passaram o tempo durante esses eventos. Mas estou morrendo por dentro, porque tenho uma paixão por isso e eles não se importam mais.

Hoje, a pessoa que está sempre contra mim me disse para parar de dizer "Eles disseram que é com isso que se comprometeram com este Sprint" porque, nas palavras dele, "Nós nunca concluímos um Sprint. Apenas movemos tarefas e assumimos novas no próximo Sprint para preencher uma cota. Realizamos o KanBan. Então, pare de dizer isso. "

Entendo por que ele diz isso, mas ele não parece perceber que é assim, porque ele e todos os demais da equipe não se importam. Eles apenas trabalham em vez de lidar com impedimentos. Eles reclamam dos impedimentos, mas não fazem nada a respeito. E quando eu tento ajudar, eles simplesmente dão de ombros.

Eles costumavam dar a mínima, mas nos últimos dois anos sua vontade caiu para mais ou menos o fundo do poço.

Como posso fazê-los ver que brincar e perder tempo durante essas reuniões custa muito dinheiro à empresa?

Você pode ter ouvido muitas estatísticas sobre projetos de software com falha e chegou à conclusão de que a falha não é de natureza técnica. Os problemas tecnológicos podem ser resolvidos através de centenas de soluções técnicas, mas resolver problemas no ambiente de trabalho usando o Scrum não vai funcionar.

Minha sugestão aqui é parar completamente de olhar para isso como um problema técnico. Não é sobre Scrum, não é sobre standups diários, sprints, retrospectivas ou qualquer outra coisa assim. Você precisa entrar em contato com sua equipe e encontrar uma maneira eficaz de trabalhar que a satisfaça, assim como você e seus superiores.

Se eles acham que os diários são uma má idéia, você não deve pedir que eles façam diários e tente inserir seu raciocínio neles. Pense por si mesmo o que os diários lhe oferecem. Verifique com sua equipe se eles valorizam essas vantagens também. Descubra por que eles não compartilham sua compreensão - como na compreensão do ponto de vista deles, não como na convencê-los de qualquer coisa. Em seguida, verifique se os diários realmente ajudam sua equipe ou se você pode conseguir mais com algum outro mecanismo. O engraçado dos mestres do Scrum é que eles são servidores de sua equipe - você pode muito bem servi-los abolindo completamente o Scrum.

Em resumo, pare de se concentrar no Scrum e volte ao básico da agilidade. Você pode começar do início com o manifesto ágil : valorize indivíduos e interações sobre processos e ferramentas.

Na minha experiência, as equipes desiludidas precisam começar com retrospectivas eficazes. É por isso que, na minha opinião, as retrospectivas são a única parte obrigatória de um processo ágil. Tudo o resto está sujeito a alterações através das retrospectivas.

Em retrospectivas eficazes, você não apenas reclama dos seus problemas, escolhe pelo menos um desses problemas e identifica possíveis soluções para ele, e tenta a solução na próxima iteração. Na próxima retrospectiva, você fala sobre como essa solução funcionou ou não e faz outros ajustes, se necessário, ou escolhe outro problema para resolver.

Quando os membros da equipe perceberem que têm o poder de efetuar mudanças reais em seus processos, ficarão mais dispostos a se envolver.

O processo retrospectivo é o motivo pelo qual, se você visitar todas as equipes de uma empresa que se sai bem ágil, elas o farão de maneira um pouco diferente. Temos algumas equipes que fazem Kanban, algumas que fazem XP, outras que fazem stand-up segunda-feira, quarta-feira e sexta-feira.

Se sua equipe não gostar de como você lida com a ressaca, pense em algumas abordagens diferentes. Conquistei desenvolvedores muito relutantes apenas ouvindo consistentemente retrospectivas e tentando soluções.

Ok, então vamos começar com dificuldade - grande parte do problema está com você - Você ouve, mas não ouve. Sua equipe está dizendo claramente quais são os problemas. Você precisa resolvê-los em vez de culpar sua equipe.

Planejamento

Para eles, o planejamento é apenas uma perda de tempo, porque acabamos de transbordar para o novo Sprint e não concluímos o trabalho de qualquer maneira, então, por que se preocupar?

Exatamente. Se você consistentemente falhar em alocar a quantidade correta de tempo para as tarefas, e elas são subestimadas constantemente, isso tem efeitos muito negativos:

• Os desenvolvedores sentem que estão constantemente sob pressão.
• "Não consigo fazer nada a tempo".
• Como o processo não funciona, eles o consideram um desperdício de tempo.

Solução : corrija suas estimativas usando a combinação de:

• Pontos da história (como uma combinação de tempo e risco).
• Não permita tarefas em um sprint com mais de 55 SP
• Estimativas comparativas
• Programação baseada em evidências

Como uma base para isso, é absolutamente necessário para controlar o tempo que realmente levou para terminar tarefas anteriores, isto inclui testes, documentação escrita, escrever testes, treinamento do usuário final, os esforços de integração, implantação. etc.

Depois de ter um tempo total para uma determinada tarefa, você pode basear o tempo esperado nessas tarefas anteriores.

Pergunte a todos os membros se a tarefa que lhes foi dada parece mais complicada ou mais fácil do que a seleção de tarefas anteriores, ajuste o número de tarefas alocadas com base nisso.

Se você nunca usou o SP antes, meu conselho é começar com 1h de trabalho realmente honesto com Deus = 5SP como orientação. Lembre-se de que, no ambiente de desenvolvimento habitual, você receberá talvez 6 por dia, portanto, 30SP / dia no máximo . Nunca permita uma tarefa que demore mais de 2 dias para entrar no quadro. Idealmente, na minha experiência, você deve ter 2 tarefas por dia.

Se você não realizar o Planejamento corretamente, o restante das atividades do Scrum parecerá uma perda de tempo (incluindo o Planejamento).

Retrospectivo

Durante a Retrospectiva, sinto que eles querem dizer "Pare de fazer Scrum". Uma pessoa faz, mas as outras ficam em silêncio e eu tenho que lidar com isso toda vez.

Lembra-me de Daily beatings will continue until morale improves!e dois dos trabalhos anteriores. Se você não remover impedimentos, eles estão corretos, indicando que é uma perda de tempo.

Mais uma vez, ouça o que as pessoas estão realmente dizendo. Se as reclamações levantadas durante a retrospectiva não são tratadas, por que se preocupar em fazê-las?

Assim:

• Considere as técnicas do Six Thinking Hats para melhorar a comunicação.
• Reduza o tempo gasto na Retrospectiva, no máximo 30 minutos.
• Garantir que as reclamações levantadas durante a Retrospectiva sejam tratadas antes da próxima.

SCRUMs diários

O Daily Scrum é novamente apenas uma perda de tempo para eles, porque nenhum deles se incomoda em conversar e planejar o dia. Eles apenas declaram: "Eu trabalhei na tarefa X ontem e vou trabalhar nisso novamente hoje". E na maioria das vezes eles brincam até eu ficar mais severo.

Parece que você tem dois problemas aqui: as reuniões do SCRUM são muito longas e seu planejamento e criação de tarefas são péssimos.

Ambos podem fazer parecer que uma reunião de scrum é uma perda de tempo.

Para o comprimento SCRUM:

• Tente 15 minutos no máximo.
• Tente todos de pé.
• Fórmula fixa:
  • O que você tem feito ontem?
  • O que você está planejando hoje?
  • O que os membros da sua equipe (não você!) Devem saber sobre a tarefa, como isso os afetará.
• Não se preocupe com impedimentos, se você não quiser lidar com eles.

Esta é uma segunda evidência de que seu planejamento prejudica sua situação - se você não tem nada específico para relatar, isso significa que geralmente a tarefa é muito grande e tudo o que você poderia dizer era: eu estava trabalhando nisso.

• Divida as tarefas nos pontos de bala.
• Verifique se as tarefas são pequenas o suficiente para levar menos de um dia. Idealmente, a tarefa da IMO deve durar ~ 3h e ser equivalente a cerca de 13 SP, para que você possa fazer 2 por dia na maioria das condições.

Lidando com a equipe

Hoje, a pessoa que está sempre contra mim me disse para parar de dizer "Eles disseram que é com isso que se comprometeram com este Sprint" porque, nas palavras dele, "Nós nunca concluímos um Sprint. Apenas movemos tarefas e assumimos novas no próximo Sprint para preencher uma cota. Realizamos o KanBan. Então, pare de dizer isso. "

Ele tem razão. Você está errado. Você está fazendo SCRUM bastardizado e / ou variação no Kanban. Não é culpa deles.

Entendo por que ele diz isso, mas ele não parece perceber que é assim, porque ele e todos os demais da equipe não se importam.

Eu acho que você não entende nada. Eles podem estar se importando menos do que costumavam antes, no entanto, culpá-los não apenas não irá melhorar nada, mas também pode piorar a situação. Se fosse o fundo do poço, eles poderiam realmente começar a cavar.

Eles apenas trabalham em vez de lidar com impedimentos.

E aqui eu pensei que trabalhar era o objetivo deles. Eu me pergunto quem deveria estar lidando com impedimentos ... oh, certo. Um Scrum Master. É o seu trabalho. Eles dizem o que há de errado. Você conserta. Não o contrário.

Provavelmente, é por isso que você tem tantos problemas na Retrospectiva.

Como posso fazer com que eles vejam que brincar e circular durante essas reuniões custa muito dinheiro à empresa?

Pare as reuniões inúteis e elas vão brincar com o refrigerador de água. Veja também o parágrafo sobre espancamentos, melhorando o moral. Se eles estão usando o humor como mecanismo de defesa, você tem alguns problemas sérios, senhor!

Entre em uma piada - como no trabalho com sua equipe, não contra ela. (Quem o fuuuuuuck se importa com o dinheiro da empresa? Você é acionista agora?)

Resumir

Seu mau planejamento está fazendo com que outras partes do SCRUM falhem e todos os que participam miseráveis. Eles vêem que nada muda, nada é tratado e suas queixas não são ouvidas.

Melhore o seu planejamento e você melhorará o fluxo e a moral.

Faça seu trabalho removendo impedimentos e sua equipe progredirá mais rapidamente. Pergunte a eles o que eles acham que você deve fazer para ajudá-los.

Mais importante: ouça seu pessoal. Eles já disseram a você (e a mim) qual é o problema.

Boa sorte!

Um dos principais princípios ágeis é voltar e corrigir o que estiver errado. Isso não inclui apenas a refatoração de código e correções de bugs, mas também a correção do processo de desenvolvimento.

Então, por que você não faz uma reunião com sua equipe e vê como pode melhorar o processo de desenvolvimento? Se isso significa que não há reuniões de scrum ou stand-up, que seja.

Além disso, você está quebrando um dos princípios do manifesto ágil : "Indivíduos e interações sobre processos e ferramentas".

Por outro lado, se sua equipe pensa que o desenvolvimento iterativo é ruim, talvez você esteja fazendo errado. Não importa se você não concluir tudo o que planejou para uma iteração - sempre é possível mover as coisas para a próxima iteração. É também por isso que você marca as coisas como "tem que conter", "é bom ter", etc. Contanto que você forneça novas funcionalidades, estará fazendo isso bem.

Apenas um pequeno discurso retórico: na minha empresa anterior e atual, fizemos e ainda fazemos reuniões em pé. Pela minha experiência, eles são uma enorme perda de tempo, uma vez que cada vez que se transformam em mais de 30 minutos de reuniões de relatórios de status, e para mim fornecem pouca ou nenhuma informação. As pessoas falam sobre seus problemas, o que sinceramente não me importo.
Na minha empresa anterior, eles eram espertos, reconheceram esse problema com as empresas e os interromperam logo depois que as pessoas começaram a reclamar.

Se você gosta de assistir a um vídeo realmente bom sobre o scrum, consulte " Robert C. Martin - a terra que o Scrum esqueceu ".

Como prioridade, considero as tarefas que continuam sendo transportadas. Não cumprir as metas é extremamente desmoralizante. Você está se comprometendo com demais? Existem fatlogs que devem ser discriminados? Existem gargalos fora do seu controle? Você tem uma definição clara de "pronto"? Os requisitos são claros? As horas por desenvolvedor são razoáveis ​​(ou seja, leva em conta administrador, standups, planejamento, retrospectivas, quebras de teclado, trabalho não relacionado ao projeto).

Em seguida, abandone o que não estiver funcionando. Processo sem valor é apenas um ladrão de tempo. Os standups podem consumir grandes quantidades de tempo se não estiverem focados e não fornecerem valor à equipe. As horas podem ser melhor gastadas em outros lugares. Talvez também considere dividir a equipe se ela for muito grande.

Tente entender o que está desmotivando a equipe. Tenha retrospectivas e, mais importante, atue na saída. É igualmente importante celebrar sucessos e observar falhas.

Por fim, convém avaliar as abordagens de mestres de scrum que foram antes e que podem ter danificado a marca, por assim dizer. Eu trabalhei com um scrum master tóxico antes em que todos os problemas levantados eram adicionados à sua carga de trabalho, você sabia ou não. Resultado final: os problemas foram ignorados e todos trabalharam em sua própria área com muito pouco trabalho em equipe.

Fazer com que sua equipe feche seu sprint de forma eficaz (como pelo menos 80% das histórias), sprint sobre sprint é, na minha opinião, a coisa mais importante que você pode fazer. Se sua equipe está constantemente ausente, é uma indicação clara de que você precisa ajustar suas estimativas.

A equipe deve ser receptiva a isso, embora possa ser muito difícil fazer com que os desenvolvedores sejam mais realistas sobre as estimativas - trabalhei em uma equipe que não fechava um sprint por um ano (fechando consistentemente menos de 50% do sprint) , sempre subestimado e em todo planejamento / retrospectiva eu ​​era uma voz solitária dizendo a eles que suas estimativas são ruins, você está sendo extremamente confiante, pare de inventar desculpas pelo que o impediu de fazer a estimativa e, em vez disso, ajuste-a para refletir a realidade ( talvez mais diplomaticamente do que isso, mas esse era o sentimento básico) - Quando você está nessa posição, eu concordo plenamente com o xerife da sua equipe que diz que o processo é uma perda de tempo porque você está de fato fazendo o KonBon, independentemente de como você chama. A certa altura, sua opinião se torna validada pelas circunstâncias. Isto'

Em algum momento, é necessário redefinir as coisas, é preciso fazer com que a equipe compense drasticamente as compensações de suas estimativas apenas para colocar o sistema em movimento. Quando uma equipe começa a fechar histórias de forma consistente, deve perceber que o processo Agile é principalmente senso comum e não materializá-lo de alguma forma é prejudicial à sua produtividade. Mas, desde que o 'compromisso' e os 'objetivos de sprint' não sejam levados a sério, o que acontece quando não são alcançados de forma consistente, então tudo é uma farsa e se torna um dreno na produtividade das equipes.

Conseguir que as pessoas comprem um sprint significativamente diferente (em termos de estimativas, planejamento, comprometimento) é difícil; nessa equipe, acabei conseguindo isso devido a dois fatores. Um estava apenas coletando os dados do JIRA e dizendo "não há desculpa para isso, os números estão muito distantes, eles estão sempre em uma direção, precisamos corrigi-los, não quero desculpas no retro, quero os números a serem somados "- e o outro foi a pressão do alto escalão da gerência, que acabei explicando a eles como ..." O objetivo desse processo é tornar o cronograma do desenvolvimento previsível. Se concluirmos uma quantidade constante de trabalho a cada sprint, tudo bem, independentemente disso, nosso conselho precisa refletir com precisão o que fazemos. A gerência está mais consciente do nosso sucesso em relação ao comprometimento do que à nossa produção real, para seu próprio bem, faça a projeção alinhar-se com a produção para que pareça que você está realizando seu trabalho em vez de gastar metade de cada sprint fazendo nada. Quanto mais pessoas afastadas são desse período, mais elas apenas veem você falhando, as desculpas que você dá no retro nem sequer são algo em seu alcance, elas apenas veem você falhando. "

Eventualmente, nossa equipe ganhou força e as coisas começaram a ficar muito mais suaves e baixas e eis que começamos a ter uma produção mais alta quando o processo realmente começou a funcionar. Portanto, faça o que for necessário para começar a fechar sprints com um grau de sucesso relativamente alto. Se você não está fazendo isso, o cretino de sua equipe continuará tendo sua resistência ao Scrum validada pelos resultados e, no final, estará certo que seu processo é, na verdade, apenas uma farsa e um desperdício de tempo de todos.

Como Scrum Master, você treina e orienta a equipe a se tornar mais produtiva. A estrutura do Scrum é uma ferramenta poderosa para chegar lá, mas a estrutura do Scrum absolutamente nunca deve se tornar o objetivo por si só - caso contrário, você estará fazendo o Cargo Cult .

Parece que você faz o Cargo Cult há 3 anos e as pessoas perceberam que essa é uma péssima metodologia de gerenciamento de projetos. A boa notícia é que você tem pessoas inteligentes , elas acertaram. Infelizmente, algumas pessoas na sua empresa estão chamando de Scrum, mas, novamente, você tem pessoas inteligentes , até disseram o que a equipe está fazendo não se chama Scrum.

O planejamento é apenas uma perda de tempo, porque apenas transferimos o excesso para o novo Sprint e não concluímos o trabalho de qualquer maneira, então, por que se preocupar?

Exatamente. Porque se importar? Você precisa encontrar uma resposta, ou melhor, alterar o planejamento e o sprint para que haja um ponto no planejamento. Ou isso, ou pare de desperdiçar o tempo de todo mundo com um Sprint Planning inútil. Você pode pedir à empresa que o envie para um treinamento Scrum Master, porque executar um ótimo Sprint Planning não é trivial.

Durante a retrospectiva, [...] os outros ficam em silêncio e eu tenho que lidar com isso todas as vezes.

Se você está lidando com o mesmo problema em todas as retrospectivas, as pessoas nem se preocupam (mais?) Em falar durante a retrospectiva, isso é apenas uma perda de tempo. A menos que você ou a equipe possam, de alguma forma, resolver os problemas levantados na Retrospectiva, a reunião é apenas uma desmoralização da equipe. Questões levantadas na retrospectiva devem ser abordadas e deve haver progresso na próxima retrospectiva.

O Daily Scrum é novamente apenas uma perda de tempo para eles, porque nenhum deles se incomoda em conversar e planejar o dia. Eles apenas declaram: "Eu trabalhei na tarefa X ontem e vou trabalhar nisso novamente hoje".

De fato, por que se preocupar em desperdiçar o tempo de todos se eles apenas trabalham nas mesmas tarefas vários dias? Eles estão absolutamente corretos, que o Daily Standup é realmente inútil. O Standup facilita a colaboração estreita em muitas tarefas que podem ser concluídas em meio dia ou menos. Se suas tarefas não puderem ser divididas dessa maneira (devido a um Sprint Planning quebrado ou porque suas tarefas realmente não se encaixam bem no Scrum), não há muito sentido em realizar a reunião de Standup Diário de 5 minutos (é não mais que 5 minutos, certo?).

"Nunca concluímos um Sprint. Apenas realizamos tarefas e contratamos novos no próximo Sprint para preencher uma cota. Realizamos o KanBan na realidade. Então, pare de dizer isso."

Entendo por que ele diz isso, mas ele não parece perceber que é assim, porque ele e todos os demais da equipe não se importam.

Não, você absolutamente não entende por que ele diz isso . Você entendeu errado a causa raiz do impedimento - que precisa resolver -. Eles não se importam porque as práticas de gerenciamento de projetos da equipe são péssimas. Preocupar-se em fazer o Cargo Cult e fazer o Cargo Cult mais difícil não o impede de ser o Cargo Cult, uma das piores metodologias de gerenciamento de projetos existentes (em sua defesa: também a mais usada).

O que você pode fazer em relação à isso?

1. Ouça as preocupações deles. Mais uma vez, você é abençoado por ter pessoas inteligentes .

2. Ajude-os a resolver os impedimentos.

E é isso mesmo. Você precisará experimentar como alterar o Sprint Planning, Daily Scrum e Retrospectives para torná-los valiosos para a equipe - mesmo se você quiser deixar o rótulo do Scrum, ainda terá essas três reuniões com frequência e objetivo semelhantes. metodologia de gerenciamento de projetos por aí. Quanto à maneira como você experimentará (frequência, conteúdo, quem organiza a reunião, horário, duração etc.), é surpreendentemente fácil: pergunte à equipe. Não force suas idéias sobre eles, se for o caso, deixe-os forçar suas idéias sobre você (supondo que eles possam concordar com alguns).

Se você tem medo de perder o controle, defina alguns limites com antecedência, por exemplo:

• Os rótulos das reuniões permanecem os mesmos.
• As reuniões ainda ocorrem e a frequência das reuniões não pode ser alterada em mais de um fator de 2.
• No momento, você está experimentando, portanto, qualquer alteração dura apenas dois sprints, após o que você reverte para o padrão antigo (é melhor reservar um tempo em semanas para evitar ambigüidades quando eles querem dobrar a duração do sprint).

Acho que todo mundo está citando a mesma linha do Agile Manifesto . Farei o mesmo: "Indivíduos e interações sobre processos e ferramentas".

Se você, como mestre do SCRUM, deseja usar o SCRUM para fazer o trabalho, deve abordá-los como um indivíduo interagindo com outro. Comece a debater como melhorar o processo. Talvez você possa convencê-los a gostar do SCRUM. Talvez eles possam convencê-lo a usar um processo diferente. Vamos descobrir!

Parece que a equipe já reconhece que o sistema atual não está fazendo o trabalho. Você pode incentivá-los a acreditar que pode fazer o trabalho? Você menciona alguns exemplos. Se você estiver enchendo demais o Sprint, para que ele sempre vaze ... pare. É a sua equipe SCRUM. Ajude-os a parar de se comprometer demais. Empurre de volta a gerência para obter algum espaço para respirar. Use SCRUM para o que é bom. Use-o para apresentar os dados ao gerenciamento que eles estão pressionando o suficiente para perder o valor de seu processo. Se a gerência quiser o SCRUM como um processo, peça-lhes para ajudar a criar o espaço e a energia necessários para corrigi-lo. Como mestre do SCRUM, seu trabalho é resolver problemas para que a equipe possa ser produtiva.

Outra abordagem útil pode ser gerar um novo processo dentro do antigo. Continue executando o SCRUM da mesma maneira inútil, mas interrompa uma pequena parte do cronograma e diga "nesta parte do cronograma, vamos descobrir como usar as ferramentas corretamente". Não comprometa demais lá. Use suas métricas. Concentre-se em todas as suas reuniões lá. Apenas a parte restante do seu projeto "SCRUM" como um escudo para manter o gerenciamento feliz enquanto você e sua equipe "[descobrem] melhores maneiras de desenvolver software fazendo isso e ajudando outros a fazê-lo". Com o tempo, você desejará colocar cada vez mais tarefas valiosas nesse balde, e o balde antigo morrerá lentamente. Em breve, você terá um ambiente vibrante de desenvolvimento de software e ninguém será mais sábio.

Ou misture e combine-os. Eu trabalhei em um programa que era anti-scrum. Os clientes queriam poder adicionar novas tarefas a qualquer momento do processo e fazer com que atuássemos imediatamente. (Na verdade, esse foi um pedido sensato: o trabalho deles era altamente volátil e eles geralmente precisavam de suporte rápido ... é pelo que pagamos). Obviamente, tivemos que descobrir como lidar com as questões do "por que o X não está pronto quando você prometeu isso no sprint"? Nossa solução foi realmente criar um processo em duas etapas. Tarefas de longo prazo foram colocadas no SCRUM para priorização adequada. As tarefas de curto prazo foram colocadas em um processo homebrewed, focado na interação estreita entre cliente e desenvolvedor. Entendeu-se que os clientes eram bem-vindos para nos pressionar usando esse processo de curto prazo, mas que eles entendiam que isso fazia com que a Sprint ' linha de tempo de s e eles foram proibidos de adicionar solicitações sem ouvir e abordar simultaneamente os problemas de agendamento que eles causaram. Resultado? Funcionou. A maioria das tarefas foi colocada no processo SCRUM, como deveria ser, e as emergências interagiram perfeitamente com elas. A atitude foi "Se você quer ser um cliente, fique na fila para uma história da SCRUM. Se você quer ser um parceiro, sinta-se à vontade para descer e trabalhar conosco no dia-a-dia e fazer esse produto funcionar ! "

Digo isso porque realmente sei. Você tem um problema na alta gerência com excesso de agendamento, incapaz de definir prioridades e vontade de adicionar mais itens, mas não atrasa as datas de liberação.

Eu costumava dizer que não existe uma metodologia que possa funcionar assim, mas agora que eu vi o Kanban, digo que sim, mas apenas porque o Kanban não precisa se preocupar. Ele continua a funcionar quando supercomprometido. Ele não trará resultados mais rapidamente, mas o backup nas filas não pode ser colocado em nenhum indivíduo e, portanto, o problema de gerenciamento fica com o gerenciamento. Os relatórios de feedback mostram sobrecarga, o que está correto.

Devido a essa mudança no Scrum Masters e sua maneira de dirigir o show

Bem, isso pode ser seu problema. Um mestre do Scrum não está lá para executar um show, ele não é um líder de projeto. Ele está lá para garantir que todas as partes interessadas estejam se comunicando e a operação seja transparente.

Gostaria de saber de onde vem a equipe. Será que eles eram mais ou menos autônomos antes que o Scrum (incluindo o inevitável mestre do Scrum) fosse lançado sobre eles? Por que o Scrum foi introduzido em primeiro lugar? O que deveria resolver?

O Scrum deve fornecer orientação e sua equipe está deixando claro que eles não são úteis de forma alguma. Eles não se importam com orientação, consideram uma perda de tempo inapropriada. Aparentemente, pelo menos um tomador de decisão pensa que precisa ser guiado de qualquer maneira. Quem? Por quê? Eles têm razão?

Este é um problema não limitado ao software.

Em qualquer ambiente de trabalho, haverá pessoas diferentes com personalidades e habilidades diferentes. Mesmo se o Scrum fosse um método perfeito, ainda haveria pessoas contra ele devido a suas personalidades e habilidades.

Os desenvolvedores lidam com tarefas difíceis de maneira racional. Para poder fazer isso, cada desenvolvedor terá seu jeito de lidar com coisas que podem aparecer como aversão a coisas como Scrum. Se todos os desenvolvedores foram treinados do zero exatamente da mesma maneira, pode ser muito mais fácil usar um padrão, mas, caso contrário, será necessária uma adaptação no lado do desenvolvedor ou no gerenciamento.

Além disso, pensadores independentes (desenvolvedores e outros especialistas) geralmente não gostam de saber como fazer as coisas, porque esse é o trabalho deles e é fácil que ocorram conflitos de opinião. Scrum pode parecer um ritual inútil para um pensador lógico que normalmente analisa e age de acordo com cada questão em questão.

O texto abaixo parece sugerir onde está o problema, mas não o que é. Definitivamente, há mais do que isso. Só posso supor (por experiência) que os desenvolvedores tentaram, mas foram impedidos. Eu já vi isso muitas vezes em que os desenvolvedores querem consertar algo, mas algo sistemático (gerenciamento, política da empresa etc.) torna quase impossível, então eles desistem. Eles realmente não se importam ou não se importam apenas em fazer algo que acreditam que não ajudará (possivelmente fora da experiência).

Entendo por que ele diz isso, mas ele não parece perceber que é assim, porque ele e todos os demais da equipe não se importam. Eles apenas trabalham em vez de lidar com impedimentos. Eles reclamam dos impedimentos, mas não fazem nada a respeito. E quando eu tento ajudar, eles simplesmente dão de ombros.

Eles costumavam dar a mínima, mas nos últimos dois anos sua vontade caiu para mais ou menos o fundo do poço.

Como posso fazer com que eles vejam que brincar e circular durante essas reuniões custa muito dinheiro à empresa?

Se algo está sendo forçado a outras pessoas, cabe às pessoas forçar o método a convencê-las dos benefícios. Embora eu realmente não acredite em forçar as pessoas a fazer as coisas, sugiro que, em qualquer situação, ouça a todos e desenvolva um método que funcione no ambiente atual.

Scrum não deixa de ter suas fraquezas. É claro que posso falar por mim mesmo, mas acho que os desenvolvedores o odeiam por um bom motivo . É minha opinião sincera que não deve ser tentada .

Para entender o porquê, leia o que todo mestre de scrum deve saber sobre scrum . Não foi escrito por mim, mas tudo o que há é representativo da minha experiência, que só posso resumir como puro terror .

No meu caso, sofri especialmente com o ponto 5. Basicamente, o scrum me tratava como criança e perdedor. Agora, sou um co-desenvolvedor de recursos ajudando meus colegas ... não é de admirar o que eu preferiria!

Eu tenho um novo chefe (não-scrum) agora, que apenas anda por aí e fala com as pessoas, e sou muito grata por isso! Parte do motivo disso funcionar é que também temos uma sala de bate-papo (usamos o mais importante) para a comunicação entre desenvolvedores. Se alguém tiver uma agenda, nós a levaremos para lá. As reuniões são apenas para discussões ad-hoc de desenvolvedores, não para impor prazos artificiais diários a si mesmo.

Você obteve muitas respostas excelentes. Aqui estão mais alguns pontos que podem ser úteis:

Mudar a metodologia é difícil

É um grande desafio no espaço de trabalho, porque você trabalha sob a inércia de "é assim que fazemos as coisas" e contra a pressão dos prazos e das necessidades dos negócios.

Você está certo ao concluir que sua equipe precisa dedicar mais tempo ao planejamento, e não menos ; esse planejamento é algo em que seu tempo atualmente não é bom e precisa melhorar. O problema é que você não chega lá simplesmente ditando novas regras. Novas regras são um novo fardo antes que se tornem uma grande ajuda. E se eles não fornecerem grande valor imediatamente , você terá mais evitação do que cooperação.

Eu recomendo Roy Osherove sobre este tópico. Ele tem um breve resumo de como planejar e efetuar mudanças na sua empresa e aborda o tópico com muito mais profundidade neste vídeo .

A observação básica de Osherove é que todos os seguintes desafios precisam ser enfrentados:

Motivação pessoal: Por que alguém se importa em se comportar de uma maneira específica?
Habilidade pessoal: Eles podem literalmente fazer isso?
Motivação Social: Há pressão dos colegas por esse comportamento?
Habilidade social: as pessoas ao meu redor apóiam meu comportamento e me ajudam quando preciso de ajuda?
Motivação Estrutural: Existem recompensas / punições por bom / mau comportamento?
Capacidade estrutural: o ambiente físico suporta esse comportamento?

Você precisa aprender a dividir tarefas

Sua equipe sente que "eu trabalhei na tarefa X ontem e trabalharei nela novamente hoje", e eles parecem estar certos, no sentido de que as tarefas continuam sendo adiadas uma semana.

O que é realmente útil aqui é aprender a dividir tarefas em pequenos componentes. O que você está procurando é a resposta para a pergunta "OK, você está trabalhando na tarefa X, mas no que especificamente na tarefa X você está trabalhando hoje ?"

Algumas respostas podem ser:

• Estou aprendendo essa classe de código legado.
• Estou corrigindo um bug cujos sintomas são (SINTOMAS).
  • Se este é um bug em andamento que está demorando um pouco: "Hoje o que vou tentar é ... (PLANO)"
• Eu preciso mudar essa interface.
• Estou escrevendo testes.
• Estou integrando código não testado.

... e assim por diante. Ser capaz de observar o que você realmente pode fazer em um dia ou em uma semana é um dos grandes benefícios do Agile. Mas isso significa que você realmente precisa analisar a resolução de dias individuais, não alguma tarefa monolítica X que estará pronta sempre que estiver pronta.

Concluído vs. Entregue

Um problema comum (com o Agile e o planejamento do local de trabalho em geral) é que os prazos tendem a vir do gerenciamento, não dos desenvolvedores. Esse prazo pode estar separado do trabalho real a ser realizado - e, em particular, é provável que as coisas sejam entregues o mais rápido possível.

O problema é que "entregue o mais rápido possível" é um processo muito caótico. Incentiva a cortar cantos; codificação "rápida e suja"; ignorando diretrizes; não limpar depois de si mesmo. Incentiva a mentalidade de "tente, veja se funciona. Se sim, entregue. Se não, tente outra coisa" - e, assim, você pode ver por que ninguém pode prever quanto tempo levará algo.

Considerando que, se você estiver trabalhando metodicamente, se for rigoroso sobre planejamento e teste e assim por diante, configurou várias placas de sinalização e redes de segurança. Pode levar mais tempo - você está dedicando muito tempo a coisas que não estão promovendo a entrega imediata e ainda pode não ser muito bom nesse tipo de fluxo de trabalho - mas será muito menos volátil.

Então, uma coisa a se perguntar é: os desenvolvedores estão definindo as metas do sprint, de acordo com as necessidades e necessidades que eles realmente veem? Ou é a gerência definindo os prazos, deixando os desenvolvedores tentarem colocar seus compromissos em um cronograma de sprint?

Se os desenvolvedores não têm tempo para planejar as coisas ou trabalhar de acordo com um plano confiável, não é de admirar que não possam fazer estimativas úteis. :)

Pode ser uma opinião impopular, mas talvez você não consiga fazer nada a respeito.

Eu posso imaginar que, ao longo dos anos de existência e fluxo de líderes da equipe, pessoas que estavam realmente insatisfeitas com a equipe foram embora. O que você tem são restos de pessoas que podem reclamar, mas não estão realmente interessadas em se esforçar para melhorar a situação. Eles só querem gastar suas 8 horas de código de hackers, sem serem interrompidos por ninguém e simplesmente ir para casa no final do dia. O que você tem aqui parece ser um sério problema de motivação. E não é tarefa do scrum master resolver esse problema. É problema de quem está pagando essas pessoas.

Se esse for realmente o caso, apenas a opção real será livrar-se da equipe atual e começar do zero. Talvez deixe uma ou duas pessoas que você ache melhores na equipe e demitam ou movam o restante para equipes diferentes. Você deve pelo menos discutir essa possibilidade com seus superiores.