Reunião diária do Scrum: pontualidade sobre a presença total da equipe?

Meu entendimento é que uma reunião diária do Scrum deve ser muito rápida, organizada de maneira amigável e que exige todos os membros da equipe presentes. Porque o objetivo é manter todos atualizados com o que os outros estão fazendo.

Eu gosto das reuniões diárias do Scrum que são realizadas assim.

No meu projeto mais recente, nossos Daily Scrums são mais como uma reunião de Atualização de Status. Embora a posição seja que estamos segurando Scrums e praticando o Agile adequado.

Somos uma equipe distribuída, em 2 países diferentes, e as pessoas que estão no mesmo país não estão no mesmo escritório. Como conseqüência, temos Scrums virtuais.

O problema é que nossas reuniões sempre começam na hora, muitas pessoas ligam antes da hora de início real e, portanto, começam no primeiro segundo da reunião. Sem qualquer tolerância para pequenos atrasos.

Por exemplo, a última vez que estivemos no telefone e a pessoa que coordenava a reunião verificou se todos estavam presentes, e dissemos que um dos membros de nossa equipe ainda não estava ligado, mas que estava ligando. E me disseram para começar a compartilhar sem esperar pelo membro da minha equipe.

Além disso, todos têm muitas reuniões e, às vezes, estão de volta na reunião do Scrum, portanto é compreensível que eles cheguem durante o primeiro ou o segundo minuto da reunião.

Isso é normal para as equipes que praticam Daily Scrums? É a primeira vez que isso acontece comigo.

Não consigo encontrar nenhuma bibliografia diretamente sobre isso. Embora a presença de todos os membros da equipe seja estressada, é enfatizado também que as reuniões devem sempre começar ao mesmo tempo. Mas imagino que possa haver uma pequena tolerância de atraso.

Eu até li em um blog alguém sugerindo que o Scrum Master pode aplicar penalidades se alguém chegar "5 segundos" atrasado. Eu pensei que os Scrums deveriam ser amigáveis, e ter uma penalidade como essa parece contraproducente.

Qual é a abordagem recomendada em uma situação como esta?

Como em qualquer prática ágil, as equipes de scrum podem decidir isso sozinhas. Se isso o incomoda, você deve mencioná-lo em sua retrospectiva e tentar chegar a uma solução na qual todos estejam felizes. Talvez outros membros da equipe sintam o mesmo, mas pensam que é "exatamente como o scrum é feito".

Dito isto, nas minhas reuniões do scrum, começo no segundo, a menos que três ou mais pessoas estejam desaparecidas. Para uma reunião em que todos são obrigados a participar todos os dias, sinto que é desrespeitoso com o tempo de todos fazer o contrário. Quando eu chego atrasada, minha equipe começa sem mim. Se tivermos tempo no final, voltaremos às tarefas das pessoas que chegaram atrasadas.

Eu fui menos rigoroso com a pontualidade no passado, e o que aconteceu foi que as pessoas que apareceram pontualmente se cansaram do tempo perdido, então começaram a tentar adivinhar quando a reunião realmente começaria e, em vez disso, apareceram, o que havia acontecido. um efeito de bola de neve.

Para uma reunião diária, não é o fim do mundo se alguém ocasionalmente perde parte dela. Espero que não seja a única comunicação que você faz ao longo do dia.

Se você esperar pelas pessoas, elas ensinam que não há problema em chegar tarde. Se você começar no minuto, as pessoas serão ensinadas que precisam chegar a tempo, se quiserem participar. A programação é uma atividade profissional que requer pelo menos um mínimo de disciplina.

Dito isto, o objetivo da discussão diária é discutir o que a equipe fez ontem, o que estão fazendo hoje e conscientizar todos sobre os obstáculos. O horário programado deve ser "a primeira coisa da manhã, quando todos estiverem disponíveis", não necessariamente um horário específico no relógio. O objetivo final é trabalhar em equipe, não seguir regras rígidas. Se sua equipe é muito nova para o Agile, seguir o relógio é uma boa maneira de desenvolver suas habilidades de equipe. Se você é um time maduro, faça o que funciona para o seu time.

É assim que o Scrum funciona?

Eu sugeriria que as reuniões diárias sejam muito frequentes para qualquer atividade comercial, a menos que sua equipe seja especialmente produtiva (o que significa que elas podem produzir grandes faixas de funcionalidade em períodos muito curtos).

Se você decidir fazer tags diárias, elas não devem durar mais que 15 a 20 minutos e, sim, todo mundo precisa estar pontual ou não participa. As marcações são para o benefício dos membros da equipe, não do scrum master; as multas por falta de reuniões diárias devem ser tratadas da mesma maneira que qualquer outro atraso.

Em suma, não vejo nada de especial aqui. Eu acho que as reuniões diárias de qualquer tipo limitam a microgestão, mas se você decidir fazê-las, precisará realizá-las adequadamente.

Pessoas sobre o processo . Esse é um dos principais inquilinos do Agile, se um processo não estiver funcionando para sua equipe, descarte-o ou modifique-o. Deixe a equipe modificá-lo para atender às suas necessidades.

Pense assim: qual é o sentido do dia a dia?

É sua oportunidade de levantar obstáculos com o restante da equipe, sinalizando que você pode precisar de assistência e destacar as mudanças que afetarão os outros. É importante que você, como desenvolvedor, esteja lá.

Com uma equipe de 4 a 8 desenvolvedores, eles precisam ser rápidos e rápidos - 30 segundos cada um na maioria das vezes. Se estivesse desempenhando o papel de scrum master, eu ficaria preocupado com o início tardio das reuniões, pois aumentaria o custo da reunião. Da mesma forma, os horários variáveis ​​das reuniões criam uma distração para todos - estamos prestes a ... Eu também estaria muito ciente de equilibrar isso com as necessidades para garantir que a equipe possa apoiar-se mutuamente, de modo que possa atrasar a reunião, se necessário, porque alguém quem provavelmente seria impedido estava no telefone / banheiro.

Onde as equipes estão distribuídas geograficamente como você está descrevendo, eu estaria sinalizando isso como um impedimento para a equipe em TODAS AS retrospectivas. É flagrantemente um impedimento para o desempenho e a comunicação dos scrums que eles não estejam todos reunidos e capazes de se comunicar livremente e facilmente.

Eu estaria argumentando que isso deveria ser organizado como duas equipes de scrum separadas e o trabalho organizado para que o scrum de scrums lidasse com a comunicação internacional.