As Três Opções Reais

Scrum funciona melhor quando sua equipe entrega funcionalidades em uma cadência previsível. Sprints de duas semanas forçam uma conversa de planejamento a cada quatorze dias, uma demo que torna o progresso visível e uma retrospectiva que expõe atritos antes que se solidifiquem. Você obtém papéis definidos — um product owner que protege o backlog, um scrum master que protege o processo e engenheiros que protegem o compromisso.

A estrutura é o ponto principal. Equipes de produto construindo em direção a metas trimestrais precisam do ritmo de "planejamos esses oito tickets, terminamos sete, aqui está o porquê." Stakeholders obtêm previsões fundamentadas em velocidade histórica em vez de suposições otimistas. Engenheiros obtêm permissão para dizer "isso não está neste sprint" sem uma batalha política.

O custo do Scrum é a rigidez. Mudanças de escopo no meio do sprint são caras. Cerimônias tomam tempo real de calendário — uma equipe de seis pessoas gastará 4–6 horas por sprint em rituais. Se seu trabalho é orientado por interrupções ou suas prioridades mudam diariamente, essa rigidez se torna arrasto em vez de alavancagem.

Kanban otimiza para throughput em ambientes onde o trabalho não esperará pelo limite do seu sprint. Um ticket de suporte escalado às 14h não se importa que seu planejamento de sprint só aconteça na quinta-feira. Kanban diz: visualize o trabalho, limite quanto está em progresso de uma vez e puxe o próximo item de maior prioridade quando a capacidade se liberar.

O quadro é o sistema. Colunas representam estágios (A Fazer, Em Progresso, Revisão, Concluído), e limites WIP limitam quantos tickets podem ficar em qualquer coluna simultaneamente. Uma equipe de 3 pessoas com um limite WIP de 4 em "Em Progresso" não pode iniciar novo trabalho até que algo avance. Essa restrição é o que torna Kanban mais do que uma lista de tarefas — ela força a equipe a terminar antes de começar.

Kanban se adequa a equipes de operações, equipes de plataforma e qualquer grupo cujo trabalho recebido é imprevisível no tempo, mas relativamente uniforme em tamanho. Também funciona bem como um passo intermediário — equipes incertas sobre Scrum podem executar Kanban por um mês para construir hábitos de fluxo antes de adicionar sprints.

Nem toda equipe precisa de uma metodologia agora. Uma equipe de 3 pessoas sentada na mesma sala, entregando um produto, com um backlog curto e conversa diária — essa equipe já tem ciclos de feedback. Adicionar cerimônias de sprint ou quadros Kanban por cima não cria valor; cria overhead pelo overhead em si.

Os fundamentos deste curso — disciplina de controle de código, tickets significativos, estimativa básica e um entendimento compartilhado do que "concluído" significa — são suficientes para entregar bem para equipes onde o custo de coordenação é baixo. O sinal de que você precisa de mais estrutura não é "lemos sobre Scrum e parece profissional." São dores concretas: handoffs perdidos, surpresas crônicas no momento da demo, trabalho que fica ocioso porque ninguém sabia que estava bloqueado, ou novos membros da equipe que não conseguem se integrar sem uma semana de acompanhamento.

Se esses problemas não estão acontecendo, permaneça aqui. Revisite esta decisão em três meses ou quando a equipe crescer além de cinco pessoas.