Por que e por que razões os desenvolvedores podem não gostar do "scrum diário"? [fechadas]

Existem vantagens em manter o scrum diário, como:

1. A equipe é coordenada entre si
2. Todo mundo sabe que quantidade de tarefa foi realizada
3. O gráfico de burndown fica cada vez mais completo
4. O quadro de tarefas é atualizado
5. Não dura tanto, 15 minutos não matam ninguém

No entanto, recentemente (após 6 meses de implementação e uso do scrum), sinto que nossos desenvolvedores não gostam mais do scrum diariamente. As pessoas apenas atualizam o quadro de tarefas, sem explicar o suficiente e parece que estão entediadas. Vejo que, por qualquer motivo, não o seguramos, eles se tornam mais felizes.

Só não sei o que poderia estar errado com isso. Há algum motivo mencionado em algum lugar para as desvantagens que o "scrum diário" pode ter para uma equipe? Quais poderiam ser as razões para os desenvolvedores se cansarem do scrum diário?

Tive experiência em participar de uma equipe "SCRUM" com vários empregadores. Parece-me que os gerentes tomam a "reunião diária de scrum" como o ponto principal do SCRUM e o definem como objetivo, em vez de tê-lo como é: um meio para alcançar um ciclo de desenvolvimento mais eficaz .

Muito rapidamente, as reuniões de 15 minutos se tornaram 45 minutos, as atualizações eram ineficazes porque as pessoas estavam ocupadas bocejando e pensando "quando já podemos ir" em vez de ouvir os outros, e isso também quebraria a rotina das pessoas (eu, por exemplo, estou uma pessoa coruja, e começar a trabalhar às 9 da manhã para essa reunião idiota todos os dias é uma razão suficientemente boa para eu deixar o emprego).

Quando os gerentes tomam uma idéia que pode ser boa se aplicada corretamente e a levam ao extremo - eles obtêm exatamente o oposto dos resultados esperados. Eu pessoalmente acho que os mais reuniões que participo - menos trabalho que estou fazendo. Tenho 2 reuniões regulares por semana no meu calendário e geralmente pulo uma delas. As reuniões são para gerentes, deixe os desenvolvedores fazerem seu trabalho.

Tenho certeza de que muitos entusiastas do SCRUM dirão "Mas é tão maravilhoso" - bem, salve, já ouvi tudo.

Eu acharia o dia-a-dia chato e inútil se sentisse que havia pouco ou nenhum valor nele. Existem algumas coisas que podem reduzir a utilidade de um standup diário.

• As informações compartilhadas nunca pertencem ou me afetam de forma alguma.
• Ausência de propriedade da equipe e todos sempre trabalhando em seus próprios projetos.
• Ausência de comunicação da equipe fora do standup.
• Falta de progresso visível ou comunicado.
• Ausência de informações para compartilhar.

Estes estão fora do topo da minha cabeça, mas sempre há mais razões possíveis.

Talvez você deva perguntar diretamente aos desenvolvedores por que eles não parecem estar interessados? Se você quer mais / melhor comunicação, deve começar com você.

Alguns dos problemas encontrados nas reuniões diárias do SCRUM:

• aqueles que duram muito tempo. Você não quer nenhum gerente nessas reuniões diariamente, porque elas são a causa principal desse tipo de problema. Veja como eles costumam ser os que usam uma cadeira (sim, ter que defendê-los é motivar as pessoas a serem rápidas)
• ter que ouvir sobre alguém (ou 2 ou 3 desenvolvedores) descrevendo qualquer problema isolado que ele tenha, em vez de decidir decidir agendar outra reunião real mais tarde para discutir o assunto com os interessados
• horas estúpidas. Essas reuniões não precisam ser de manhã: você não está falando sobre o que fez ontem e nem sobre o que fará hoje; você está falando sobre o que fez entre a última diária e esta e decide o que fará até a próxima.
• falta de propriedade do aplicativo para os desenvolvedores. O SCRUM funciona se os desenvolvedores não forem tratados como macacos de código. O primeiro sinal de que o processo está errado é quando os desenvolvedores não são os que avaliam quanto tempo algo levará para ser feito.
• horas estúpidas novamente. Se parte da equipe começou a trabalhar em algumas coisas e está "na zona" quando o dia acontece, isso se torna um incômodo. Um bom momento para tê-los diariamente é quando ninguém deve trabalhar (depois do almoço, por exemplo, ou antes de começar algumas discussões durante o almoço).

O tempo é o assassino para muitos. Os programadores gostam de codificar tarde, dormem até tarde e entram depois da correria da manhã. Ter que estar no cargo em um horário fixo - muito cedo para eles. E tarde demais para quem chega mais cedo e já começa a trabalhar.

O fluxo é outra questão. Um programador em fluxo com algum recurso trabalha até tarde da noite, volta para casa e volta recarregado e pronto para continuar. Ter que participar de uma reunião com questões não relacionadas à maior parte do tempo pode distraí-lo.

Minha observação é com muita frequência que essas reuniões são para os gerentes parecerem e sentirem que estão realmente fazendo algo, em vez de serem úteis para a equipe e o projeto.

Por exemplo, uma equipe é designada para executar uma série de pequenas correções de bugs em diferentes projetos. Eles realmente não estão trabalhando em equipe, mas como indivíduos. No entanto, como a política da empresa / departamento o exige, o líder / gerente da equipe realiza uma reunião diária de qualquer maneira. Tudo o que é realizado é dedicar mais de 15 minutos para uma reunião inútil e abordar 15 a 30 minutos de distração e falta de produtividade antes e depois da reunião.

Agora, eu vi o scrum se sair bem em um projeto que tinha prazos apertados e exigia muita coordenação entre as pessoas que trabalhavam em várias peças. Nesse contexto, era um ótimo sistema. Mas, no contexto de "Estamos tendo uma reunião porque somos uma loja scrum / ágil e é isso que devemos fazer" pode realmente ser uma droga.

Certifique-se de que ninguém monopolize a reunião.

Se quatro dos desenvolvedores desviam seu discurso em 5 minutos, e os próximos 10 minutos são gastos ouvindo o líder da equipe detalhando todos os incríveis e impressionantes novos desenvolvimentos que ele fez, a maioria dos quais não é tão surpreendente nem tão impressionante como ele pensa que são, as pessoas ficam entediadas muito rapidamente.

Recue um momento e pense em sua equipe:

• Eles estão trabalhando efetivamente?
• As tarefas são concluídas no prazo?
• O código é robusto e bem escrito?
• A equipe garante que nada caia nas fendas?
• A equipe se coordena para não duplicar o trabalho ou pisar nos dedos um do outro?

Se sua resposta para todas essas coisas for "Sim", talvez você deva considerar por que deseja forçar o trabalho ocupado, como reuniões diárias, gráficos de burndown e quadros de tarefas em sua equipe. Que valor isso acrescenta? Deseja gerar dados burocráticos apenas para sua diversão ou está tentando tornar a equipe mais produtiva?

Houve um declínio na produtividade desde que os scrums diários pararam ou tudo está passando do mesmo jeito que antes? Se nada mudou, por que continuar as reuniões?

15 minutos. Esses 15 minutos (mais o tempo para se preparar para isso) transmitem informações novas e úteis suficientes entre os membros da equipe para melhorar a produtividade das equipes no dia seguinte em mais de 15 minutos? Se não houver essa quantidade útil de conteúdo scrum todos os dias, os membros da equipe provavelmente estão pensando em fazer muito mais progresso em direção às metas se saíssem dessa reunião o mais rápido possível e voltassem ao trabalho.

Se você deseja apenas atualizar o quadro e o gráfico com frequência, coloque cópias de rascunho em um wiki.

Sugiro que você realize a reunião retrospectiva para ver "O que correu bem" e "O que não correu bem" e ver se os desenvolvedores listam a reunião Stand-up diária como uma perda de tempo. Então você precisaria reorganizá-lo um pouco.

Minha experiência pessoal:

• O objetivo é saber o que estamos fazendo hoje e onde estávamos ontem. Em vez de manter a agenda, ele se resume a uma discussão técnica sobre bloqueadores entre duas pessoas e as outras 15 ficam entediadas. Identifique o problema, mas discuta fora
• As pessoas não entram na sala de reuniões a tempo, e isso se torna um ciclo feito por alguns de propósito. Portanto, o Scrum Master precisa ter uma discussão silenciosa com eles fora da reunião para garantir que eles comecem e terminem no prazo.
• Já atualizamos os gráficos de burndown fora da reunião do Scrum, para que esse não seja o principal objetivo do stand-up diário.

A resistência surge quando: 1) Eles são usados ​​para forçar as pessoas a se apressarem às 9h. É um estresse extra quando o trem está atrasado. 2) Liderança ruim do scrum. O líder deve dizer às pessoas para tirar as coisas da linha, em vez de as pessoas ficarem ouvindo algo que não as afeta. 3) Conteúdo sem valor. Esta é novamente uma questão de liderança do scrum. Supõe-se que seja um fórum para abordar gargalos, problemas de trajetória e possíveis colaborações. O que realmente acontece é que todo mundo apenas diz o que espera trabalhar naquele dia, o que não serve para nada. 4) De pé. Eu não vou ficar de pé. A lógica por trás da posição era que ela encoraja as pessoas a serem breves. As pessoas, na verdade, apenas se irritam independentemente.

Eu consegui e fiz parte de equipes de scrum muitas vezes. Os principais motivos pelos quais os desenvolvedores não gostam do scrum são:

• Como eles são executados por um scrum master muito ruim, se ele se transformar em 45 minutos, o scrum master precisa melhorar o controle do scrum.
• A maior e de longe a mais honesta razão pela qual eles não gostam disso é porque é muito difícil esconder uma ética de trabalho ruim, ou seja, mais descaradamente, ela mostra pessoas preguiçosas. Alguns desenvolvedores com quem trabalhei são chocantes, demoram dias realizando tarefas que devem ter um trabalho de 30 minutos. Um bom PM deve remover as barreiras para os desenvolvedores, o que significa que eles devem ser capazes de executar suas tarefas em um sprint. Os desenvolvedores não gostam disso porque precisam se levantar todos os dias e demonstrar o progresso que fizeram. Causa ansiedade quando eles não conseguem demonstrar progresso por alguma razão. Se é por causa de um problema válido, um bom scrum master deve resolvê-lo o mais rápido possível.

O problema surge quando os mestres do scrum não têm autoridade, habilidades ou capacidade para resolver problemas de bloqueio. Na verdade, eu vi alguns problemas apenas enterrando, esperando que eles desaparecessem. Isso é desastroso.

Francamente, em 99% das reuniões diárias do scrum que participei, praticamente todas as discussões / perguntas / respostas poderiam ter sido sanadas com alguns e-mails.

Sinceramente, acho que precisamos mostrar mais razões válidas para NÃO termos reuniões. Crie ambientes onde, quando for a hora de encurralar todos em uma sala pessoalmente, é melhor que seja uma boa razão e seja organizado para maximizar a eficiência do tempo.

Eu odeio reuniões em geral, e preferiria usar videoconferência, telefones, e-mails, qualquer coisa que me permita entrar ou permanecer no meu trabalho sem ter que me levantar e interromper meu fluxo de produtividade.

Pessoalmente, acho que se você tiver mais de quatro reuniões em um período de 8 horas, os projetos não serão bem gerenciados.

Existem muitos fatores que contribuem para a tensão sobre as reuniões. Considere estes como alguns dos motivos importantes pelos quais as reuniões podem custar mais do que valem:

• Foco - software versus reuniões
• Gerenciamento - os gerentes precisam de medição
• Personalidade - introvertidos vs. extrovertidos
• Tempo - interrupções, tempo de Maker e Manager
• Objetivos, Prioridades

Cada um desses fatores é explicado abaixo,

Foco - Gosto de desenvolver software, e isso inclui pensar nos desafios (problemas), criar soluções, criar o software e reuniões desviar o foco das tarefas que o compõem. Existe um estado chamado " Fluxo ", em que um desenvolvedor está imerso no desafio (problema), construiu um modelo mental da solução e tem um foco completo na criação da solução. Um desenvolvedor pode trabalhar até meia-noite, sair apenas para comer e dormir e depois retornar a um estado próximo de onde saiu.

Os desenvolvedores precisam evitar distrações, e muitos acham que há vantagens em codificar até altas horas da noite (evitam ruídos, telefonemas, escritórios ocupados e colegas que não desenvolvem interrompendo seu trabalho). E quando você trabalha até as 10, 11 ou 12 da noite, não é razoável ir trabalhar mais tarde (10, 11, meio-dia?). É razoável esperar que os desenvolvedores trabalhem das 9h à meia-noite?

As reuniões do Scrum (e qualquer) distraem o desenvolvedor de seu objetivo principal, que é a criação de software.

Gerenciamento - Os gerentes precisam medir para serem bem-sucedidos, daí a necessidade de agendas, entregas, cronogramas, prioridades e reuniões para medir e relatar o progresso e expor dependências, atrasos e áreas de risco. O desafio do Scrum é que um gerente precisa dessas coisas, mas o desenvolvedor precisa se concentrar. As reuniões atendem ao gerente e fornecem uma maneira de o gerente obter, medir e acompanhar o status e os progressos, mas as reuniões raramente fornecem utilidade aos desenvolvedores. Considere que os gerentes agregam mais valor ao lidar com distrações, remover barreiras e permitir que os desenvolvedores se concentrem na criação de software.

Existem soluções para a necessidade de reuniões. Um gerente pode visitar seus desenvolvedores, solicitar relatórios de status, adotar um protocolo para quando as interrupções são menos invasivas ou adotar uma política que o desenvolvedor os notifique sobre o progresso quando o desenvolvedor for interrompido. Veja a discussão do tempo para saber por que isso é importante.

Personalidade - considere que algumas pessoas são introvertidas e outras são extrovertidas. Os extrovertidos desfrutam de interações sociais e são recarregados por eles. Os gerentes são geralmente extrovertidos (porque os extrovertidos geralmente são melhores com interações sociais), embora os introvertidos possam ser bem-sucedidos como gerentes. Os introvertidos podem se divertir e até se destacar nas interações sociais, mas são recarregados pela solidão. Os desenvolvedores geralmente são introvertidos e conseguem trabalhar sozinhos (ou em pequenas equipes) porque não "precisam" de interações sociais; eles podem ser felizes trabalhando sozinhos em problemas (embora os extrovertidos também possam ser desenvolvedores). As reuniões diárias do scrum podem se tornar reuniões sociais, boas para extrovertidos, mas não tão boas para introvertidos.

Tempo - os desenvolvedores não podem escrever código enquanto estão nas reuniões. Tampouco podem pensar em problemas difíceis (a menos que estejam fazendo um brainstorming), enquanto se distraem com as reuniões. Os desenvolvedores precisam de grandes blocos de tempo ininterrupto para se concentrar na criação de software. Reuniões são interrupções que distraem seus esforços. Quando você está imerso na solução de um problema por horas, está quase pronto, e alguém diz "hora do scrum", você é interrompido e talvez perca horas de trabalho enquanto "muda de marcha". Ou você ficou no trabalho até 23:00, saiu do trabalho, viajou para casa, dormiu no problema, acordou, voltou para o trabalho pronto para resolver o problema e depois foi interrompido após uma hora trabalhando no problema, porque é "hora do scrum".

Paul Graham tem um excelente artigo sobre o Maker Time vs. Manager Time, que explica esse problema muito melhor do que eu. Basta dizer que uma interrupção da reunião, planejada ou não, pode interromper o fluxo e forçar um desenvolvedor do tempo do Maker para o tempo do gerente. Acredite, você quer desenvolvedores no tempo do Maker.

Objetivos, prioridades - desenvolvedores e gerentes têm objetivos e prioridades diferentes. Os gerentes têm o ônus de rastrear agendas, minimizar custos, garantir que seus relatórios sejam responsáveis ​​e que eles executem. Os desenvolvedores têm o objetivo de criar o software que lida com os desafios / problemas. Esses objetivos não estão em conflito, mas é o mecanismo de comunicação que cria a tensão. As reuniões atendem às necessidades do gerente e otimizam o tempo do gerente, mas entram em conflito com as necessidades do desenvolvedor. As reuniões do Scrum descartam a primeira regra das reuniões, "têm uma agenda" e tendem a vagar mais. E as reuniões são usadas para otimizar a comunicação (para o gerente), mas custam o tempo do desenvolvedor (interrupções, perda de fluxo, etc.).

Qual é o objetivo? Construir software que atenda às necessidades, de forma rápida e com qualidade, enquanto as restrições são (qualidade, tempo, custo, processo). O Scrum e outras metodologias ágeis reconhecem a restrição do processo, tentam minimizar esse fator e foram bem-sucedidas porque minimizam essa restrição. Mas adicionar reuniões custa tempo e a interrupção custa ao desenvolvedor muito mais do que a duração da reunião.

Modifique a reunião para garantir que ela traga benefícios:

1. Programe-o em um horário que ofereça alguma conveniência. Por que não pode ser 30 minutos após o início do trabalho para que todos possam revisar o e-mail e organizar seus pensamentos para a reunião. Brevidade requer planejamento. Os despreparados podem divagar para sempre.
2. Identifique os problemas que poderiam ter sido evitados se um problema tivesse sido comunicado durante a reunião. Todo mundo precisa entender qual é o objetivo.
3. Faça o que for preciso para reduzir ao mínimo a contribuição de todos. Não é o lugar para debate. Incentive as pessoas a agendar reuniões fora da reunião diária, com foco em um tópico que precise de discussão. Regra: apenas uma pessoa fala de cada vez.

Todos os reclamantes precisam ter certeza de que não estão contribuindo para o problema. Se você pode alcançar seus objetivos para o scrum diário sem ter um de maneira menos dolorosa, gostaríamos de ouvi-lo.