É sempre aceitável ter discussões não relacionadas a check-in nas reuniões do Scrum Daily Standup?

Espero que as pessoas me entreguem uma pergunta potencialmente óbvia. Já trabalhei em várias organizações que têm reuniões diárias de scrum. Algumas organizações são realmente rigorosas em usar apenas o scrum para check-in (as "três perguntas" - o que você fez ontem, o que está fazendo hoje, possui algum bloqueador?), Mas algumas outras organizações que tendem a ter outras informações gerais anúncios ou discussões técnicas detalhadas.

Ouvi o argumento, como neste artigo , de que permitir discussões não relacionadas ao check-in como este é um erro - a reunião do scrum não deve ser usada para anúncios gerais do Scrum Master, discussões técnicas etc.

O principal dano que vi disso é que as reuniões podem durar mais do que o necessário (e é irritante ser forçado a participar de uma discussão de detalhes que não são relevantes para mim).

É bastante claro que discussões que não estão relacionadas a todo o grupo e não fazem parte das "três perguntas" não devem fazer parte do processo. No entanto, se houver outros anúncios relevantes para todo o grupo e precisarem ser discutidos de qualquer maneira, é prejudicial discuti-los naquele momento (e não em uma reunião ou email separado)?

O objetivo do Daily Scrum é que a Equipe de Desenvolvimento revise as últimas 24 horas e atualize seu plano para as próximas 24 horas.

Tudo o que atingir esse objetivo e puder ser coberto em 15 minutos é exatamente para o que serve o Daily Scrum, conforme o Guia do Scrum. Se você tiver conversas mais longas que precisam acontecer, mantenha uma nota constante do que elas são e, no final do Daily Scrum, divida em grupos menores que se preocupam com esse tópico.

O objetivo do Daily Scrum é descobrir soluções para os problemas. Faça isso depois ...

Claro que é aceitável, mas concentre-se nas coisas importantes primeiro. Se ainda houver tempo nos 15 minutos, o que é bastante comum para uma equipe de desenvolvimento de 5 pessoas que está fervilhando (porque sincronizam com mais frequência durante o desenvolvimento), não tenho problemas com comunicações e / ou anúncios extras. Enquanto os adiarmos até o final do Diário.

Como Scrum Master, garanto que a equipe responda às três perguntas principais de alguma forma.

O Daily Scrum é um evento de 15 minutos para a Equipe de Desenvolvimento sincronizar atividades e criar um plano para as próximas 24 horas.

Às vezes, é necessária uma breve discussão técnica para sincronizar a equipe. Como Scrum Master, asseguro-me de ajustar a caixa de tempo de 15 minutos e interromper discussões mais longas a serem realizadas após o stand-up.

A equipe de desenvolvimento ou os membros da equipe geralmente se reúnem imediatamente após o Daily Scrum para discussões detalhadas ou para adaptar ou replanejar o restante do trabalho da Sprint.

Olhando de uma perspectiva não-Scrum e mais ágil. Concentre-se no que funciona e no que não funciona para a equipe. Apenas certifique-se de que a equipe decida e experimente as alterações, se acharem que isso as tornará mais eficazes e produzirão software de qualidade superior.

Os membros da equipe devem ter em mente o objetivo da discussão - ou seja, permitir que os outros contribuam para questões que podem levar mais tempo quando mantidas em sigilo ou dentro de um círculo limitado. Por outro lado, não seria muito ágil evitar problemas que são importantes e dizem respeito a toda a equipe, mas não se enquadram no critério de diretrizes estabelecido no livro de bolso do Scrum. Seria estúpido agendar uma reunião separada apenas por causa de uma regra que obviamente visa economizar tempo.

Nem sempre pode ser claro para um orador qual é o problema dele. Se permitir que ele gagueje por um tempo, deixe claro para outra pessoa que ele está lutando ou seguindo um caminho sem saída, você pode chegar a algum lugar depois de tudo. Estar muito preocupado com a forma também pode prejudicar a produtividade e frustrar as pessoas.

Dependendo da cultura, a posição pode ser rigorosa ou incluir também questões sociais. Nunca deve ser um evento irracional que seria considerado "zumbi scrum".

Muitas vezes há uma dicotomia entre o que várias pessoas insistem veementemente em Scrum e o conceito de pessoas sobre processos.

Se houver informações a transmitir, em última análise, é uma decisão judicial. Se é provável que cause uma quantidade significativa de discussão, é melhor mudar para outro momento. Se é apenas algo rápido, como tempo de inatividade do servidor, etc., isso pode ser feito de vez em quando. É claro que haverá sombras entre as opções. Nesse caso, o scrum master deve apenas sugerir que seja colocado offline depois de 15 minutos (ou o que seja).

De qualquer forma, eu estaria inclinado a tê-lo no final depois que o processo de stand-up usual for concluído.

Você perguntou: "é prejudicial?" mas as outras respostas abordadas principalmente "esse é o objetivo da reunião?". Acho que essas são perguntas diferentes. Realmente pode ser prejudicial quando você coloca outros itens da agenda na reunião, especialmente se ela se tornar habitual. As paradas demoram um pouco todos os dias, geralmente na hora mais produtiva do dia, pela manhã, quando as pessoas têm muita energia. Você pode minar essa energia diretamente das pessoas, se elas não puderem contar com uma espera pelo tempo que for necessário e não mais, e inteiramente relevante para elas.

As pessoas vão começar a aparecer tarde, porque estão envolvidas em algo "mais produtivo". Eles nem sequer aparecem em alguns dias. Outras pessoas aparecerão tarde ou nem todas, porque "todo mundo" aparece tarde ou não aparece. Os problemas se combinam e as paradas deixam de ser tão úteis para o seu propósito original. Isso parece extremo, mas eu já vi isso acontecer. Se você fizer isso, tenha muito cuidado com o que leva.

A maioria das equipes nas quais eu participei às vezes realiza reuniões de design logo após a stand-up, e tudo bem se usada com moderação, mas honestamente, eu obtenho melhores resultados se eu disser aos meus colegas de equipe que em breve serei bloqueado precisando de entrada no projeto e eu ' vou marcar uma reunião para aquela tarde. Isso também lhes dá tempo para refletir sobre o problema e, depois do almoço, as pessoas entram em crise e querem uma mudança de ritmo. Além disso, dessa forma, você não faz com que as pessoas que competem sejam as primeiras a realizar sua "mini-reunião" após o stand-up para que possam sair.

É claro que eu nunca advogaria cegamente fazer algo ou não fazer algo apenas porque um cara aleatório na Internet (até eu) disse a você. Indivíduos e interações sobre processos e ferramentas. Se você decidir introduzir alguns itens adicionais da agenda em suas reuniões de stand-up, recomendo trazê-lo à tona na retrospectiva subsequente, ver se a equipe achou isso perturbador ou não e fazer os ajustes necessários. Por fim, cada equipe tem um nível de conforto diferente e terá idéias diferentes sobre o que é apropriado ou não.

ATUALIZAÇÃO: Devo esclarecer: 15 minutos é o tempo MÁXIMO que você deve considerar com QUALQUER standup - um standup eficiente seguindo a regra abaixo geralmente nunca é superior a 5 minutos no máximo e se você pode destilar esse tempo ainda mais, melhor ainda. Novamente, a maioria das discussões que você considera relevantes pode ser facilmente discutida entre os membros da equipe, fora do processo simples de check-in diário, em que um standup deve estar na sua forma mais pura.

Regra prática que me prendi e me aprofundou durante projetos com amigos e aperfeiçoei em ambiente profissional:

• Ontem

O que você fez ontem individualmente para avançar no projeto e, se relevante, afetou outra pessoa.

• Hoje

Como acima, mas hoje

• Bloqueadores

Qualquer coisa que possa causar um, dê alarme, não importa o quão trivial (significa que alguém pode vir e verificar seu código ou fazer uma verificação de sanidade)

Qualquer outra coisa é uma distração. Isso pode significar um assunto que "possa" parecer relevante para o progresso do projeto. É bastante duro, mas é MUITO eficaz para fins de XP.

O objetivo da reunião de pé é uma comunicação eficaz. Faça disso seu objetivo, em vez de seguir as regras cegas. Desde que você postou esta pergunta, você está no caminho certo.

Todas as suas preocupações são válidas. Embora possamos tentar antecipar se isso cria algum problema, eu responderia sua pergunta sugerindo que você tentasse.

Evite o seguinte:

1. Tendo reuniões muito longas.
2. Muitas pessoas preferem receber os anúncios em outro lugar. Fazer isso durante uma reunião agendada é tentador, mas não abuse. A maioria das pessoas odeia fazer reuniões.
3. As informações não se aplicam a todos. Algumas exceções são boas de vez em quando.
4. Toda reunião tem anúncios por hábito e não por necessidade. Seja profissão.

Tome decisões informadas e educadas e não se esconda atrás de aplicar demais ou tomar regras muito literalmente.

A maioria dos modelos Agile fornece uma excelente estrutura inicial para equipes que são novas em um processo ágil. Isso não significa que eles não possam ser alterados para atender às suas necessidades. Se esses anúncios não melhorarem a comunicação, não faça. Parece simples, mas ...