Quando usar: ao assumir ou avaliar a liderança de um time ágil. Como: primeiro alinhe o "porquê" do projeto com o time (propósito, engajamento em nível de equipe); depois construa ambiente onde cada um possa contribuir e ter sucesso (pessoas); só então otimize processo, buscando resultado (entrega frequente + reflexão), não um processo "perfeito". Trade-offs: exige abrir mão de coordenação centralizada; leva tempo pra construir confiança, mas sem isso as outras práticas ágeis (autogestão, retrospectiva honesta) não funcionam.
Quando usar: início de qualquer projeto ágil, mesmo informal. Como: responda por que o projeto existe, quem se beneficia, o que "pronto" significa, e como o time vai trabalhar junto; complemente com um "contrato social" (valores, ritmo sustentável, DoR/DoD, regras de reunião). Trade-offs: processo formal ajuda times novos a se alinharem rápido, mas não é obrigatório se o time já sabe como trabalhar junto.
Quando usar: ao fim de um release, a cada poucas semanas, quando o time estagna, ou em qualquer marco — não precisa de iteração fixa pra acontecer. Como: colete dados qualitativos (sentimento) e quantitativos (medição); ache causa-raiz; limite os itens de melhoria à capacidade real do time de executá-los na próxima iteração; meça o resultado depois. Trade-offs: escolher poucos itens e concluir todos bate escolher muitos e não terminar nenhum.
Quando usar: preparar histórias pra próxima iteração/fluxo. Como: limite a no máximo ~1h/semana de refinamento; trabalhe em trios (dev+teste+analista/dono do produto); use spikes quando houver dependência incerta. Trade-offs: mais de 1h/semana é sinal de sobre-preparação do dono do produto ou lacuna de habilidade do time — não é "cuidado extra", é desperdício.
Quando usar: times que precisam de colaboração intensa diária. Como: baseado em iteração — 3 perguntas em rodízio (o que concluí / o que vou concluir / impedimentos); baseado em fluxo — ler o quadro da direita pra esquerda, perguntando o que precisa avançar. Trade-offs: se virar reunião de status, é sinal de time vindo de cultura preditiva — deixe qualquer membro facilitar, não o líder/PM, e resolva problemas fora do standup (parking lot).
Quando usar: sempre que houver funcionalidade concluída pra mostrar. Como: dono do produto participa e aceita/recusa histórias; cadência mínima recomendada de 2 semanas pra não perder feedback útil. Trade-offs: time que não demonstra nem entrega não aprende rápido o suficiente — sinal de que precisa de mais coaching, não de "esperar terminar mais coisa".
Quando usar: acompanhar progresso real (não previsão). Como: baseado em iteração — velocidade + burndown/burnup; baseado em fluxo — lead time/tempo de ciclo/tempo de resposta + diagrama de fluxo cumulativo. Trade-offs: velocidade não é comparável entre equipes diferentes (cada uma tem sua própria unidade); "% pronto" é medida de substituição, sempre prefira funcionalidade de fato concluída.
Quando usar: sustentar velocidade de entrega no médio prazo. Como: integração contínua, testes em todos os níveis (unitário/sistema/fumaça), ATDD/TDD/BDD, spikes pra aprendizagem crítica. Trade-offs: negligenciar qualidade técnica cobra retrabalho e débito técnico depois — não é luxo de time maduro.
Quando usar: negociar relacionamento cliente-fornecedor em contexto ágil. Como: estrutura em várias camadas (separa itens fixos de dinâmicos), ênfase em valor entregue (marcos por valor, não artefato intermediário), incrementos de preço fixo, T&M com teto, T&M gradativo (bônus por antecipação/multa por atraso), opção de cancelamento antecipado, opção de escopo dinâmico, aumento de equipe (fornecedor incorporado à estrutura do cliente). Trade-offs: preço fixo por incremento protege o cliente mas limita flexibilidade do fornecedor; aumento de equipe é o mais colaborativo mas exige mais confiança mútua.
Quando usar: organizações que não conseguem virar ágeis de uma vez. Como: adicione técnicas iterativas primeiro (aprendizagem/alinhamento); teste num projeto de risco baixo/médio; só depois acrescente técnicas incrementais e escale pra projetos mais complexos. Trade-offs: mais lento que "big bang", mas reduz risco de rejeição cultural — trate a própria transformação como backlog priorizado, com experimentos curtos.
Quando usar: desenhar ou avaliar um Escritório de Gerenciamento de Projetos num contexto ágil. Como: funcione como consultoria interna com tailoring por projeto (valor); atraia adoção entregando valor real em vez de impor padrão (convite); cubra competências além de gestão de projeto tradicional (multidisciplinar). Trade-offs: exige o EGP provar valor antes de pedir adoção — mais lento que mandato, mas adoção "pega" de verdade.
Quando usar: decidir se um projeto deve ser ágil, preditivo ou híbrido. Como: pontue em grupo (nunca sozinho) 9 perguntas em 3 categorias (cultura, equipe, projeto) de 1 a 10; plote num radar — centro = ágil, bordas = preditivo, espalhado = híbrido. Trade-offs: é diagnóstico de discussão, não veredito automático — o consenso das partes interessadas pode sobrepor o resultado.
Quando usar: antes de qualquer tailoring que remova uma prática ágil. Como: identifique o que a prática contrabalança (ex. colocação física + requisitos leves; testes rígidos + refatoração corajosa) antes de removê-la. Trade-offs: remover sem entender geralmente cria mais problema do que resolve.