Pular para o conteúdo
Casa de Júniors
← Todas as publicações
Artigopor Fernando Roque

Daily, o que divide uma cerimônia de útil para insuportável.

O manifesto ágil nunca pediu uma reunião diária de quinze minutos. Por que a daily apodrece e o que faz ela sobreviver.

  • #processo
  • #agil
  • #times

Para os não iniciados a daily é uma prática que veio do Scrum, um dos vários frameworks que se apresentam como implementação do espírito ágil e é fácil confundir a prática com o espírito, porque a prática é o que sobra depois que a empresa contrata uma consultoria, compra um curso e distribui certificados.

O que a daily deveria ser

Na formulação original do Scrum, a daily (ou “Daily Scrum”) é um momento para o time se realinhar: o que mudou desde ontem, o que ainda falta para terminar o que foi combinado, e o que está travando alguém. Não é uma reunião de status para quem não está no time. É o time conversando com o time, sobre o trabalho do time. A pessoa que relata “terminei X, hoje vou fazer Y” não está prestando contas a um chefe está dando informação para os colegas ajustarem o próprio trabalho.

O que ela vira

Na prática, em muitos lugares, a daily vira uma fila de pessoas recitando um relatório de status, uma de cada vez, para um gestor ou tech lead que está ali principalmente para ouvir se está tudo dentro do prazo. Ninguém ajusta nada com a informação recebida, porque a decisão de ajustar não é do time é de quem está observando. A reunião continua existindo porque está no calendário, não porque resolve algo.

Esse é o sintoma mais comum de processo que “apodreceu”: a prática sobrevive, o motivo dela morreu. O mesmo acontece com retrospectivas que sempre terminam nas mesmas três ações que nunca são feitas, ou com sprints de duas semanas que nunca mudam de escopo no meio, tornando o “sprint” só um nome bonito para “quinzena do calendário”.

Por que isso acontece

Um padrão comum: a daily apodrece quando o time não tem autonomia real para agir sobre o que descobre nela. Se alguém diz “estou travado há dois dias” e isso não muda a prioridade de ninguém, a informação não tem para onde ir, ela só fica registrada. Reunião que gera informação sem gerar decisão tende a virar teatro.

Outro fator é o tamanho do time. O manifesto ágil pressupõe times pequenos, com comunicação direta. Quando a “daily” junta dez, quinze pessoas de squads diferentes só porque estão no mesmo projeto grande, o formato de “cada um fala a sua parte” deixa de caber em quinze minutos e vira, de novo, uma leitura de status só que mais longa.

O que faz uma daily sobreviver e como decidi modificar para que ela não se torne algo que o time evita

Algumas condições que aparecem em times onde a daily continua viva:

  • A reunião muda algo. Se alguém trava, a prioridade do dia muda para desbloquear essa pessoa, na hora, não na próxima retrospectiva.
  • O público é o time, não um relatório para terceiros. Se a gerência quer saber status, isso pode ser resolvido de outro jeito (um board visível, um resumo assíncrono), sem transformar a conversa do time em audiência.
  • Cabe em pouco tempo porque o time é pequeno. Quando não cabe, o problema geralmente não é o formato da reunião, é o tamanho do time ou a granularidade do trabalho.
  • Existe permissão para dizer “estou travado” sem custo. Se admitir bloqueio é visto como falha pessoal, ninguém vai admitir, e a reunião perde a única informação que valia a pena coletar.

O que isso significa para quem está começando

Para quem é júnior, a daily costuma ser a primeira exposição a processo de time formal, e é fácil achar que o formato visto no primeiro emprego é “o jeito certo”, vale desconfiar, se a daily do seu time parece um desfile de status sem consequência, o problema não é você, e provavelmente não é nem o Scrum (é que a prática se separou do motivo que a justificava). Perceber essa diferença é mais útil, no longo prazo, do que decorar o vocabulário de qualquer framework.

Leia também

Ver todas →
Artigo

Omarchy, o Arch mais estético e “plug-and-play”

A distro de DHH entrega um desktop Arch mais Hyprland pronto e bonito. O preço é usar a visão de outra pessoa como sua (algo que os usuários de arch tendem a odiar).

por Casa de Júniors
  • #linux
  • #ferramentas
  • #opiniao
Artigo

Especificação primeiro, prompt depois

Vibe coding funciona em protótipo e desmonta em projeto grande. A especificação escrita antes é o que torna IA útil em escala.

por Fernando Roque
  • #ia
  • #processo
  • #codigo