Existe uma quantidade absurda de conteúdo sobre Scrum. Certificações, livros, cursos, consultores. E mesmo assim, a maioria dos times que "faz Scrum" está na verdade fazendo algo bem diferente do que o framework propõe — e culpando o Scrum quando as coisas não funcionam.
Depois de anos aplicando metodologias ágeis em contextos muito diferentes — startup em crescimento acelerado, time remoto, integração pós-aquisição —, tenho algumas opiniões formadas sobre o que funciona de verdade.
O problema não é o Scrum
Quando um time diz que "tentou Scrum e não funcionou", vale perguntar: qual parte do Scrum vocês de fato implementaram?
O Scrum real tem três pilares: transparência, inspeção e adaptação. Se o daily virou um relatório de status para o gestor, a retrospectiva virou um teatro sem consequências, e o sprint review não muda nada no próximo planejamento — você não está fazendo Scrum. Está fazendo uma versão cara e burocrática de gestão tradicional com vocabulário ágil.
O framework funciona quando o time usa as cerimônias para tomar decisões reais, não para documentar o que já foi decidido.
Daily: quinze minutos ou uma hora?
A daily de quinze minutos é possível. Exige disciplina, não talento.
As três perguntas clássicas ("o que fiz, o que farei, há impedimento?") têm um problema: incentivam relato individual em vez de coordenação coletiva. O time responde para o Scrum Master, não uns para os outros.
O que funcionou melhor nos times que liderei foi reorganizar a daily em torno do board, não das pessoas. Você olha para cada item em progresso e pergunta: o que precisa acontecer para isso avançar hoje? A conversa flui naturalmente, os impedimentos aparecem com contexto, e quinze minutos são suficientes porque ninguém está narrando — todo mundo está resolvendo.
Retrospectiva que não muda nada
A retrospectiva é a cerimônia mais poderosa do Scrum e a mais desperdiçada.
O sinal de alerta é quando as mesmas reclamações aparecem sprint após sprint sem resolução. Isso significa uma de duas coisas: os problemas identificados não viram ações concretas, ou as ações não têm dono e prazo.
O formato que adotei: cada item de melhoria vira uma tarefa real no próximo sprint, com responsável definido. Não uma intenção — uma entrega. A retrospectiva seguinte começa verificando o que foi feito. Simples assim. A taxa de execução aumenta dramaticamente quando as melhorias têm o mesmo peso que as features.
Velocidade não é produtividade
Um dos maiores equívocos em times ágeis é usar velocity como indicador de desempenho. Velocity mede consistência de estimativa, não quantidade de valor entregue.
Quando a gestão começa a cobrar aumento de velocity sprint a sprint, o time responde do jeito mais racional possível: infla as estimativas. Os story points crescem, a "produtividade" aparente cresce, e o output real pode estar caindo.
O que importa medir é o que chega aos usuários e qual impacto tem. Às vezes um sprint com velocity baixa entregou mais valor do que três sprints consecutivos com velocity alta.
Times remotos e o Scrum distribuído
Trabalhar com times distribuídos em fusos diferentes muda fundamentalmente a dinâmica das cerimônias. A daily síncrona pode não ser possível para todo mundo no mesmo horário. A review pode precisar ser gravada. A retrospectiva assíncrona raramente funciona.
O que aprendi: em times remotos, a documentação escrita do que foi decidido é tão importante quanto a cerimônia em si. Uma decisão tomada numa call que não fica registrada em lugar nenhum é uma decisão que vai ser tomada de novo — com atrito e confusão.
O que o Scrum não resolve
Nenhum framework resolve problema de confiança. Se o time não se fala com honestidade, se há medo de apontar impedimentos, se o gestor usa a daily para microgerenciar — o Scrum vai apenas tornar esses problemas mais visíveis, não resolvê-los.
Isso é, na verdade, uma das propriedades mais valiosas do framework: ele expõe disfunções organizacionais rapidamente. O problema é que muitos times interpretam essa exposição como falha do Scrum, em vez de sinal de que há algo mais profundo para resolver.