Por que minha daily não funciona?
Identifique os problemas que estão acabando com esse encontro tão importante.

Na teoria, as Daily Meetings (reuniões diárias) deveriam ser feitas para entender a situação da sprint naquele momento (naquele dia), saber o que foi feito, o que será feito e também o que está impedindo o progresso do time. Este é um bom momento para inspecionar e adaptar o plano da sprint, mapear situações adversas para, rapidamente, montar um plano de ação para garantir sua entrega.
Mas na prática não é bem assim, né?
Às vezes, o desenvolvedor não está interessado na reunião; Às vezes a informação vem fragmentada demais e, por isso, fica difícil entender a real situação comentada; Às vezes o assunto se distorce e vira um comunicado do gerente/diretor, ou então, um bate-papo pra decidir onde almoçar ou como foi o happy-hour do dia anterior. O encontro tem (ou deveria ter) apenas quinze minutos e parece que demora uma hora. Deveria resultar em informações importantíssimas mas, pela desvalorização que dão a reunião, ela acaba virando mais um bate-papo informal, que dificilmente tem algum conteúdo que agregue. Com todo esse cenário turbulento, pode ainda acontecer da equipe abolir o encontro por não enxergar o seu real valor.
Essa é uma realidade de muitas empresas, equipes e projetos.
Como podemos tornar nossas dailys mais efetivas? Como fazer com que todos enxerguem o valor deste evento Scrum?
- Informações fragmentadas ou telefone sem-fio
Quando trabalhamos com muitas histórias (3+) e há uma quebra no raciocínio pois uma hora um desenvolvedor está falando da história A, o próximo fala da história C, o terceiro comenta a história B e então voltam a falar da história A… Percebe o tanto de informações que estão sendo passadas uma em cima da outra? Desse jeito fica difícil entendermos o que está acontecendo. Uma sugestão é fazer a cerimônia baseada por história, ou seja, o Scrum Master poderia ensinar o time a perguntar o status da história A, e os envolvidos falam tudo o que tiverem para falar daquela atividade naquela hora, para que o tópico seja unificado e fechado de uma vez, e então, passar para a próxima história (tópico).
- Desinteresse dos participantes ou “me deixa trabalhar”
É quando o desenvolvedor responde as 3 perguntinhas básicas de forma relaxada, já virando os olhos para a reunião, olhando o relógio a cada minuto ou ainda casos em que o desenvolvedor se estende muito sobre um impedimento ou solução encontrada que na verdade deveria ser discutida depois, fora daquela reunião. Para estas situações, o facilitador deve explicar a importância da cerimônia apresentando os seus benefícios.
Outro cenário comum é o desenvolvedor estar no ápice do seu foco resolvendo um problema, ter que parar o raciocínio devido ao horário da daily e ele ficar pensando naquilo durante a reunião.
Para este último cenário, o que posso compartilhar é que o melhor aproveitamento que tive em dailys (no aspecto lugar e hora) foi estar próximo a porta de saída da empresa, 15 minutos antes do horário de almoço, pois saindo do ambiente de trabalho (telefones tocando, e-mails pulando na tela, pessoas batendo na porta da sala) diminuía a distração dos participantes durante a reunião, e o horário próximo ao almoço mantinha o tempo de ação para a resolução de impedimentos no período da tarde, fazia com que o pessoal fosse pontual e ainda não deixava a reunião prolongar ou entrar em assuntos fora de hora (pois todos estavam com fome). Você pode ainda ver com o time sugestões de horários para que se adeque o melhor possível a rotina deles, e com o menor impacto (quebra de raciocínio, atrasos) possível.
- “Mesmo horário e lugar reduzem a complexidade”
Foi difícil entender essa frase de primeira. Que complexidade é essa? Em grandes corporações, em que há a necessidade de reservar salas, reunir pessoas que estão em diferentes locais e ter todas essas pessoas disponíveis num mesmo horário, é necessário ter um local e horário definido para que a reunião ocorra e seja produtiva.
Sem contar que, dependendo do horário (pouco depois do início do expediente, ou logo depois do almoço), pode fazer com que algumas pessoas só comecem a realmente trabalhar depois do encontro para que não haja uma quebra de raciocínio.
- Blablabla diário ou “é só um comunicado”
Esse caso é quando ainda estão esperando alguém chegar e o papo se estende para algo totalmente nada a ver com o foco da daily, ou quando está no meio da reunião e teu chefe aproveita que está todo mundo na sala para dar “apenas um comunicado rapidinho, não vai atrapalhar”.
Todo o time é responsável por manter o foco da conversa e valorizar esse tempo. Se houver alguma outra discussão, o facilitador interrompe o debate e os envolvidos podem voltar ao assunto após o término do encontro.
Precisa dar um comunicado para todos do time? Agende um horário, mande e-mail ou espere o final da reunião para começar outra.
Quer debater qual a melhor forma de resolver aquele problema? Chame os envolvidos para falar disso depois da daily, nem todo mundo está interessado nessa discussão.
- Ausência ou atraso de participantes
No item acima mencionei quanto a esperar alguém para começar a daily, não está correto, mas citei pois acredito que ocorra bastante. A reunião já tem hora e local fixamente definidos para evitar situações assim. Valorize o tempo dos coleguinhas, o seu tempo não é mais importante que o do outro. Comece a reunião no horário estabelecido e, provavelmente, na próxima vez os atrasados terão mais cuidado. Converse com o envolvido e, se o problema persistir, escale a situação à um superior funcional.
- Debate técnico ou Conferência Nacional dos Especialistas
Citei este item em algum ponto acima e acho que vale reforçar: Daily não é uma reunião para discutir a melhor forma de resolver um problema, explicar porque o conceito X é bom nesse caso etc. Não sei se é uma questão de mostrar serviço para o chefe (sim, se esse for o caso, a pessoa considera o Scrum Master como chefe), mas tem gente que aproveita para falar de tudo que fez no dia anterior, até mesmo as coisas mais insignificantes a pessoa faz questão de detalhar.
Primeiro que nem todo o desenvolvedor presente está interessado ou participará de alguma coisa relacionada à sua geniosa maneira de resolver aquele problema, segundo que o Scrum Master pode não ter domínio técnico e não entender bulhufas da conversa. Não há necessidade de explicar como você fez funcionar, apenas comente (brevemente) o progresso ou problemas enfrentados.
Mantenha o foco da conversa e, se precisar de ajuda técnica sobre alguma coisa, peça depois da reunião.
Daily Meeting não é um report de atividades.
- Saiba aproveitar as informações
Legal ver que o time não está tendo impedimentos para as atividades… Mas será que a coisa está andando bem? Como você pode combinar informações para ter insights que vão dar valor a sua daily? Esta é pro Scrum Master.
Liste as tarefas e questione o relacionamento entre elas, existe alguma dependência ou impacto? Isso já está sendo analisado? Um gráfico de burn-down, junto das informações reportadas, podem clarear o motivo daquele ritmo desacelerado de dois dias atrás.
- Daily em pé
Pra alguns isso vai ser bizarro, mas já participei de dailys em que ficávamos sentados apenas por preguiça e querendo ou não, isso tende a ultrapassar o timebox da reunião visto que as pessoas estão mais confortáveis. A daily em pé gera um leve desconforto físico que torna o papo mais rápido, evitando assim assuntos paralelos.
E você, quais problemas enfrenta na sua reunião diária? Como seu time ultrapassa essas barreiras?
