Kollabe
Retrospectivas
Poker de Planejamento
Standups
Quebra-gelos
Preços
Painel de Controle

Postagens

15 Anti-padrões de Scrum Que Matam a Produtividade de Seu Time

Equipe ilustrada passando por movimentos mecânicos em uma reunião de standup com expressões sem vida, um quadro ágil estagnado ao fundo
Matt Lewandowski

Matt Lewandowski

Última atualização 16/02/202615 min de leitura

Seu time segue o Guia Scrum. Você tem um Product Owner, um Scrum Master e um time de desenvolvimento multifuncional. Você executa cada cerimônia conforme agendado. E ainda assim, nada parece estar funcionando. O problema geralmente não é que você está pulando eventos de Scrum. É que você os está fazendo de maneiras que parecem produtivas, mas que realmente diminuem a capacidade do time de entregar. Estes são anti-padrões: práticas que parecem normais, talvez até corretas, mas que silenciosamente destroem os ciclos de feedback dos quais Scrum depende. Aqui estão 15 dos mais comuns, organizados por área de cerimônia. Se você reconhecer mais que alguns, seu processo precisa de cirurgia, não um Band-Aid.

Anti-padrões de Planejamento do Sprint

O planejamento do sprint define a direção para todo o sprint. Quando dá errado, tudo que vem depois sofre. Para um guia completo sobre como fazer bem, veja como executar reuniões efetivas de planejamento de sprint.

1. Sem objetivo de sprint

Como parece: O time puxa itens do topo do backlog até a capacidade se esgotar. Não há tema coerente ou objetivo, apenas um monte de tickets. Por que é prejudicial: Sem um objetivo de sprint, o time não tem um propósito compartilhado. Quando o escopo precisa ser negociado no meio do sprint (e sempre precisa), não há um framework para decidir o que cortar. Cada ticket parece igualmente importante, então nada é cortado e o sprint transborda. Como corrigir: Comece cada sessão de planejamento do sprint articulando o objetivo do sprint antes de selecionar itens do backlog. O objetivo responde "por que este sprint importa?" Se o Product Owner não consegue articular um, o backlog provavelmente precisa de reestruturação. Para uma abordagem passo a passo, o guia de cerimônias Scrum cobre o fluxo completo de planejamento.

2. O Product Owner Dita o Escopo

Como parece: O PO entra no planejamento com uma lista pré-selecionada de itens e diz ao time o que eles vão completar este sprint. Os desenvolvedores acenam. Por que é prejudicial: Planejamento de sprint é uma negociação, não uma atribuição. Quando o PO dita o escopo, os desenvolvedores perdem a propriedade de seus compromissos. Eles param de questionar prazos irrealistas porque aprenderam que não importa. O resultado: sobrecarga crônica e esgotamento silencioso. Como corrigir: O PO propõe prioridades e explica o contexto comercial. Os desenvolvedores selecionam o que podem realisticamente se comprometer a fazer com base em sua capacidade e na Definição de Pronto. O Scrum Master facilita isso como uma conversa bidirecional, não uma entrega.

3. Estimativa Durante Planejamento em Vez de Refinamento

Como parece: O time encontra itens de backlog não estimados durante o planejamento do sprint e gasta 30+ minutos debatendo pontos de história para cada um. Por que é prejudicial: Planejamento é para selecionar e se comprometer com o trabalho, não para dimensioná-lo. Quando a estimativa se infiltra no planejamento, a reunião fica longa, a energia cai e o time se apessa pela parte real do planejamento. Pior ainda, o PO não consegue priorizar adequadamente itens cujo custo é desconhecido. Como corrigir: Estime durante sessões de refinamento de backlog realizadas ao longo do sprint. Use Planning Poker para manter a estimativa estruturada e limitada em tempo. Quando os itens chegam ao planejamento do sprint, eles já devem ter estimativas e critérios de aceitação claros. Se suas estimativas sofrem de pensamento de grupo ou viés de ancoragem, Planning Poker Anônimo pode ajudar.

4. Sobrecarga Crônica

Como parece: O time se compromete com mais trabalho do que pode terminar, sprint após sprint. Itens não terminados são carregados. Números de velocidade parecem bons no papel porque as estimativas estão infladas. Por que é prejudicial: Sobrecarga treina o time a tratar compromissos de sprint como aspiracionais em vez de reais. Também corrói a confiança dos stakeholders. Quando tudo está "quase pronto," ninguém consegue prever quando algo vai realmente ser entregue. Como corrigir: Rastreie a velocidade real (completada, não comprometida) e use-a como o limite superior para o próximo sprint. Deixe buffer para trabalho não planejado. Se o time consistentemente termina cedo, eles podem sempre puxar mais itens do backlog.

Anti-padrões de Daily Standup

O daily standup existe para ajudar desenvolvedores a se coordenar. Quando se desvia desse propósito, se torna a reunião que todos temem. Para uma abordagem mais saudável, veja nossas ferramentas de standup e alternativas assincrone.

5. Relatório de Status para o Scrum Master

Como parece: Os membros do time enfrentam o Scrum Master ou gerente e relatam o que fizeram ontem. A conversa flui para cima, não lateralmente. Desenvolvedores não estão falando entre si. Por que é prejudicial: O standup se torna uma mini-revisão de desempenho em vez de uma ferramenta de coordenação. Pessoas otimizam suas atualizações para parecerem produtivas em vez de expor bloqueadores. O time perde oportunidades de se ajudar mutuamente porque estão atuando, não comunicando. Como corrigir: O Scrum Master deve se afastar física e verbalmente. Literalmente fique fora do círculo. Direcione perguntas para "o que o time precisa saber?" em vez de "o que você fez?" Caminhar pelo quadro (discutindo tickets da direita para a esquerda) naturalmente muda o foco de pessoas para trabalho.

6. Durando Mais de 15 Minutos

Como parece: O standup regularmente dura 25, 30, às vezes 45 minutos. Resolução de problemas e discussões de design explodem. Pessoas começam a trazer laptops. Por que é prejudicial: Standups longos são um imposto na manhã de todo o time. Sinalizam que a reunião não tem disciplina, o que convida mais desvios. Membros do time começam a fazer múltiplas tarefas ou se desconectam mentalmente. As pessoas não envolvidas na conversa lateral acabaram de perder 30 minutos por nada. Como corrigir: Use um cronômetro visível. Quando um tópico precisa de discussão mais profunda, anote e agende um acompanhamento apenas com as pessoas que precisam estar envolvidas. A frase a usar: "Vamos discutir isso depois do standup."

7. Resolução de Problemas em Standup

Como parece: Alguém menciona um bloqueador e o time inteiro gasta 10 minutos depurando junto. Ou uma pergunta técnica provoca uma discussão de arquitetura. Por que é prejudicial: Isso confunde duas atividades diferentes: sincronizar e colaborar. O standup é para identificar problemas, não resolvê-los. Quando a resolução de problemas toma conta, pessoas não envolvidas ficam ociosas e a reunião se torna impredizível em duração. Como corrigir: Treine o time a usar standup para expor, não resolver. O formato deve ser: "Estou bloqueado em X. Preciso de ajuda de [pessoa específica]." Então essas duas pessoas se encontram imediatamente após o standup. O resto do time volta ao trabalho. Reunião de retrospectiva ilustrada onde um gerente está sentado na cabeceira da mesa enquanto membros do time parecem desconfortáveis e silenciosos, com notas adesivas em branco na parede

8. Apenas o Scrum Master Fala

Como parece: O SM passa pelos tickets de cada pessoa, pede atualizações e narra o quadro. Desenvolvedores dão respostas de uma palavra. O standup é funcionalmente um show de uma pessoa. Por que é prejudicial: Tira agência dos desenvolvedores. Quando o SM dirige a conversa, o time não está se auto-organizando; está sendo gerenciado. Também significa que o SM se torna um ponto único de falha para a coordenação. Se ele ficar doente, o standup desmorona. Como corrigir: Reveze a facilitação entre membros do time. Ou melhor ainda, elimine a facilitação explícita completamente e deixe o time caminhar pelo quadro por si mesmo. O SM deve observar, notar padrões e trazer problemas sistêmicos para a retrospectiva em vez de fazer microgerenciamento da sincronização diária.

Anti-padrões de Retrospectiva

A retrospectiva deveria ser o motor da melhoria contínua. Quando quebra, o time para de aprender. Para um guia sobre como executar retros bem, veja como executar uma retrospectiva ágil efetiva, e tente nossa ferramenta de retrospectiva para formatos estruturados.

9. Sem Acompanhamento de Itens de Ação

Como parece: O time identifica boas melhorias durante a retro. Itens de ação são escritos em notas adesivas. Duas semanas depois, ninguém se lembra do que eram. A próxima retro expõe os mesmos problemas. Por que é prejudicial: Esta é a forma mais rápida de matar o engajamento em retrospectivas. Quando as pessoas veem suas sugestões desaparecerem no vácuo, elas param de fazê-las. A retro se torna uma sessão de desabafo sem consequências, e eventualmente as pessoas param de participar mentalmente (mesmo que estejam fisicamente presentes). Como corrigir: Limite itens de ação a dois ou três por retro. Atribua um proprietário específico a cada um. Comece a próxima retrospectiva revisando os itens de ação do sprint anterior antes de qualquer coisa. Rastreie a conclusão visivelmente. Se um item de ação não puder ser concluído em um sprint, é muito grande. Divida-o.

10. Mesmo Formato Cada Sprint

Como parece: Cada retrospectiva usa o mesmo formato. Iniciar/Parar/Continuar. Cada. Único. Sprint. O time sabe exatamente o que esperar e parou de pensar criticamente sobre suas respostas. Por que é prejudicial: Familiaridade gera piloto automático. Quando o formato nunca muda, membros do time pré-calculam suas respostas antes da reunião começar. Eles param de descobrir novos insights porque as perguntas não os forçam a pensar diferente. A retro se torna um exercício de checkbox. Como corrigir: Reveze os formatos de retrospectiva. Use o formato Veleiro um sprint, o 4Ls o próximo, depois um exercício de linha do tempo. Cada formato revela diferentes tipos de insights. Nosso post ideias de retrospectiva tem uma biblioteca de formatos para escolher. A variedade em si sinaliza que essa reunião é importante o suficiente para investir.

11. Presença de Gerente Mata a Honestidade

Como parece: Um gerente ou stakeholder se senta na retrospectiva. O time apenas discute tópicos seguros: horários de standup, preferências de ferramentas, acústica da sala. Ninguém menciona os problemas reais. Por que é prejudicial: Retrospectivas requerem vulnerabilidade. As pessoas precisam nomear fracassos, apontar falhas de processo e às vezes abordar atrito interpessoal. Nada disso acontece quando alguém com autoridade sobre sua carreira está na sala. O time muda para "teatro de sucesso" e os problemas reais permanecem ocultos. Este é um caso clássico de baixa segurança psicológica que silenciosamente mina as cerimônias ágeis. Como corrigir: Gerentes não devem participar de retrospectivas a menos que o time os convide unanimemente. Se a cultura organizacional exige visibilidade de gerenciamento, compartilhe um resumo de itens de ação (não a discussão bruta) após a retro. O trabalho do Scrum Master é proteger esse limite.

12. A Retrospectiva "Tudo Bem"

Como parece: Ninguém levanta preocupações. O time concorda que as coisas estão indo bem. A retro termina em 10 minutos. Mas as métricas do sprint contam uma história diferente: compromissos não cumpridos, tempos de ciclo crescentes, dívida técnica crescente. Por que é prejudicial: "Tudo bem" quase nunca é verdade. Geralmente significa uma de três coisas: o time não confia o suficiente no ambiente para falar, o formato da retro não revela problemas reais, ou o time desistiu da melhoria porque sugestões anteriores foram ignoradas. Como corrigir: Comece com dados, não sentimentos. Mostre as métricas reais do sprint: tendência de velocidade, itens carregados, bugs escapados, tempo de ciclo. Deixe os números iniciar a conversa. Use coleta de entrada anônima antes da retro para que as pessoas possam levantar tópicos sensíveis sem anexar seu nome. E reconsidere se os anti-padrões 9 e 11 estão em jogo.

Anti-padrões de Sprint Review

O sprint review é a chance do time de obter feedback real dos stakeholders. Quando se torna uma apresentação unidirecional, aquele ciclo de feedback se fecha. Para um guia completo sobre reviews saudáveis, veja como executar um sprint review.

13. Apenas Demo, Sem Feedback

Como parece: O time apresenta uma demo polida do trabalho completado. Stakeholders assistem, acenam, aplaudem. Ninguém faz perguntas ou sugere mudanças. A reunião termina com "ótimo trabalho, time." Por que é prejudicial: O sprint review não é uma demo. É um evento de inspecionar-e-adaptar. Se stakeholders não estão fornecendo feedback, o time está construindo no vácuo. Expectativas desalinhadas se compõem ao longo de múltiplos sprints até que uma grande mudança de curso se torna inevitável (e cara). Como corrigir: Estruture o review em torno de perguntas, não apresentações. Depois de cada incremento ser mostrado, pergunte explicitamente: "Isto corresponde ao que você esperava? O que você mudaria? O que devemos priorizar em seguida?" Dê aos stakeholders o produto para interagir, não apenas assistir. Envie a demo antecipadamente para que a reunião possa focar na discussão.

14. Sem Presença de Stakeholders

Como parece: O sprint review é assistido apenas pelo time Scrum. Sem clientes, sem usuários, sem stakeholders comerciais. O PO às vezes joga o papel dos três. Por que é prejudicial: Sem perspectivas externas, o time perde contato com as necessidades reais dos usuários. O PO se torna um gargalo para todo o feedback, e suas suposições não são questionadas. O time constrói o que o PO pensa que os usuários querem em vez de validar diretamente. Como corrigir: Facilite a presença de stakeholders. Envie convites de calendário cedo. Mantenha a reunião breve e focada. Compartilhe uma agenda de uma página mostrando o que será revisado. Se os stakeholders principais realmente não puderem participar, grave o review e colete feedback assincrone. Mas não-presença persistente é um sinal de que a organização não valoriza o processo Scrum, o que é um problema que vale a pena escalar.

15. O PO Aprova ou Rejeita o Trabalho

Como parece: O sprint review se torna uma porta de aceitação. O PO revisa cada item e o marca como "aceito" ou "rejeitado," frequentemente com pedidos de mudança de último minuto. Por que é prejudicial: Isso transforma o sprint review em uma inspeção de qualidade em vez de uma discussão colaborativa. Cria uma dinâmica adversarial entre o PO e o time. Também significa que a Definição de Pronto não está fazendo seu trabalho. Se itens "prontos" podem ser rejeitados, a definição de pronto do time não é clara, ou o PO está adicionando novos requisitos disfarçados de critérios de aceitação. Como corrigir: A aceitação deve ser contínua, não agrupada no review. O PO deve estar revisando incrementos durante todo o sprint, não economizando para uma cerimônia única. O sprint review deve focar em direção estratégica e feedback de stakeholders, não em guarita de itens individuais.

Anti-padrões Organizacionais

Alguns anti-padrões não pertencem a nenhuma cerimônia única. Eles infectam todo o processo.
🧟Zombie Scrum

O time passa por cada movimento de Scrum, mas nada significativo sai. Sprints produzem incrementos que ninguém usa. Stakeholders pararam de prestar atenção. O time perdeu qualquer senso de propósito. As cerimônias acontecem, mas são vazias. Isto frequentemente vem de umafalta de segurança psicológicacombinada com disfunção organizacional que o time se sente impotente para resolver.

🔧Sprints de Endurecimento

O time dedica sprints inteiros a "estabilização" ou "endurecimento," corrigindo bugs e pagando dívida técnica acumulada durante "sprints de funcionalidade." Este é um sintoma direto de uma Definição de Pronto quebrada. Se trabalho de qualidade só é feito em sprints especiais, qualidade não é parte do processo. Construa testes, refatoração e documentação em cada sprint.

📊Velocidade como Métrica de Desempenho

Gerenciamento usa velocidade para comparar times, avaliar desempenho individual ou definir objetivos. O time responde previsivelmente: eles inflam estimativas. Uma história de 5 pontos se torna um 8. Velocidade sobe. Produção real não. Para métricas que realmente revelam saúde de processo, procure pormétricas de fluxo como tempo de ciclo e throughput.

Como Diagnosticar Seu Time

Se você não tem certeza de quais anti-padrões se aplicam ao seu time, use esta checklist como uma avaliação de saúde. Passe honestamente, idealmente como time durante uma retrospectiva.

Nosso sprint tem um objetivo claro e articulado que todo o time consegue explicar.

Desenvolvedores escolhem seu próprio escopo de sprint baseado em capacidade, não atribuições do PO.

Itens de backlog são estimados antes de entrar no planejamento do sprint.

Completamos consistentemente 80% ou mais do nosso compromisso do sprint.

Nosso standup fica sob 15 minutos e foca em coordenação, não status.

Membros do time falam entre si em standup, não apenas com o Scrum Master.

Nossos itens de ação de retrospectiva do sprint anterior foram completados.

Pessoas levantam preocupações reais em retrospectivas, não apenas logística.

Stakeholders participam de sprint reviews e fornecem feedback acionável.

Nunca temos sprints dedicados de "correção de bugs" ou "endurecimento."

Velocidade é usada para planejamento, não para avaliação de desempenho.

A Definição de Pronto do time inclui testes e documentação.

Qualquer item não verificado aponta para um anti-padrão que vale a pena abordar. Comece com aquele que causa mais dor e corrija-o antes de passar para o próximo. Tentar corrigir tudo ao mesmo tempo é seu próprio anti-padrão.

Conclusão

Anti-padrões são insidiosos porque parecem processo. O time está fazendo Scrum, executando cada cerimônia, preenchendo cada campo no Jira. Mas os resultados não estão lá. Reconhecer o padrão é o primeiro passo. Corrigi-lo requer honestidade sobre o que está realmente acontecendo na sala e a coragem organizacional para mudá-lo. Comece com um. Corrija-o. Prove que funciona. Depois aborde o próximo. É assim que a melhoria contínua deveria funcionar, um sprint de cada vez. Se você está procurando ferramentas que apóiem cerimônias Scrum mais saudáveis, Kollabe fornece Planning Poker com estimativa anônima, retrospectivas com formatos estruturados, e standups assincrone que mantêm times distribuídos alinhados.

Um anti-padrão é uma prática que parece produtiva ou segue a estrutura de Scrum na superfície, mas que realmente mina a capacidade do time de entregar valor. Anti-padrões frequentemente se desenvolvem gradualmente conforme times encontram atalhos ou caem em hábitos que contornam a intenção por trás dos eventos e papéis de Scrum.

Zombie Scrum descreve times que passam por todos os movimentos de Scrum sem nenhum dos resultados. Sprints acontecem, cerimônias rodam conforme agendado e quadros são atualizados, mas o time perdeu a conexão com stakeholders, propósito e a capacidade de inspecionar e adaptar. O termo foi popularizado por Johannes Schartau, Christiaan Verwijs e Barry Overeem. Tipicamente é causado por uma combinação de disfunção organizacional, baixa segurança psicológica e uma desconexão entre o time e as pessoas usando seu produto.

Comece com a retrospectiva. É a única cerimônia explicitamente projetada para melhoria de processo. Levante o anti-padrão específico com dados: mostre métricas de sprint, aponte padrões ao longo de múltiplos sprints e proponha um experimento concreto para tentar por um sprint. Enquadre como uma hipótese, não uma reclamação. Se anti-padrões de retrospectiva são o problema (padrões 9-12), essa é uma conversa para o Scrum Master, que tem o mandato organizacional para proteger a capacidade do time de inspecionar e adaptar.

Sim, no curto prazo. Times podem entregar funcionalidades enquanto executam standups quebrados, pulam itens de ação retro e se sobrecarregam cada sprint. Mas não é sustentável. Anti-padrões criam custos ocultos: esgotamento, dívida técnica, confiança erosiva e rotatividade. O dano se compõe ao longo do tempo. Times que abordam anti-padrões cedo protegem sua velocidade a longo prazo e saúde do time.