Scrum

Scrum é um framework para organizar trabalho complexo em ciclos curtos, com papéis definidos, eventos recorrentes e artefatos que tornam o progresso visível. É a implementação de Agile mais adotada no mundo — e também a mais mal aplicada.

A distância entre o que Scrum propõe e o que a maioria das empresas pratica tem nome: Scrum de fachada.

Scrum organiza o trabalho em três elementos centrais: papéis, eventos e artefatos.

Papéis. O Product Owner decide o que será feito e em que ordem — é responsável pelo valor entregue. O Scrum Master garante que o framework está sendo seguido e remove impedimentos para o time. O Time de Desenvolvimento executa o trabalho e tem autonomia sobre como fazê-lo. Três papéis, sem hierarquia entre eles. Quando a empresa coloca um "gerente de projeto" acima do Scrum Master, o framework já não é Scrum.

Eventos. A Sprint é o ciclo de trabalho — bloco fixo de uma a quatro semanas ao fim do qual há algo funcional entregue. Dentro da Sprint: Sprint Planning define o que será feito, Daily Scrum alinha o time diariamente em quinze minutos, Sprint Review apresenta o resultado, Sprint Retrospective examina como o time trabalhou. Eventos com cadência fixa, não reuniões convocadas quando alguém se lembra.

Artefatos. O Product Backlog é a lista priorizada de tudo o que o produto precisa. O Sprint Backlog é o subconjunto selecionado para a Sprint atual. O Incremento é o resultado funcional entregue ao fim da Sprint.

Scrum resolve o problema de trabalho onde os requisitos evoluem, o time precisa de autonomia para decidir como executar e feedback rápido é mais valioso do que planejamento longo. Desenvolvimento de produto, criação de conteúdo, projetos de consultoria com escopo aberto — contextos onde a Sprint como ciclo de aprendizado faz sentido.

O que Scrum não resolve: trabalho com requisitos estáveis e execução repetível, projetos com interdependências fortes entre times diferentes, operações que precisam de continuidade em vez de ritmo pulsado. Usar Scrum onde o problema é de execução, não de descoberta, produz cerimônia sem substância.

Os padrões de falha são reconhecíveis. Product Owner sem autonomia real para priorizar — alguém acima decide e o PO apenas comunica. Daily Scrum que vira reunião de status para gestores em vez de alinhamento entre o time. Sprints que terminam sem incremento funcional porque "estava quase pronto". Retrospectivas que identificam os mesmos problemas sprint após sprint sem ação.

O denominador comum é a mesma estrutura de sempre vestida com vocabulário novo. Scrum sem a autonomia do time, sem o compromisso do Product Owner e sem o espaço para o Scrum Master agir é teatro organizacional.

Em PMEs, o Scrum completo raramente cabe nos primeiros estágios — os times são pequenos, os papéis se sobrepõem, a cadência de duas semanas pode ser longa demais ou curta demais dependendo do contexto.

O que vale preservar: a cadência de revisão regular, o backlog priorizado como instrumento de decisão visível e a retrospectiva como hábito de melhoria do time. Esses três elementos entregam a maior parte do valor do framework com fração da cerimônia.

Scrum funciona onde há disciplina para seguir o que o framework exige — especialmente as partes desconfortáveis: Product Owner com poder real de priorização, time com autonomia sobre o como, retrospectiva com consequências reais. Sem esses elementos, o que existe não é Scrum — é reunião diária e Sprint com outro nome. A adoção honesta do framework começa por admitir o que a organização está disposta a mudar de verdade.