Capítulo 11: Apêndice X2 — Atributos que Influenciam o Tailoring

Core Idea

Tailoring é tópico avançado: só faça depois de já ter tido sucesso com a abordagem ágil "de manual", e sempre em colaboração com quem vai ser afetado pela mudança — tailoring imposto de cima pra baixo tende a virar resistência, mesmo quando tecnicamente correto.

Frameworks Introduzidos

• Modelo Shu-Ha-Ri (progressão de habilidade): Shu (守, obedecer as regras) → Ha (破, desviar-se conscientemente das regras) → Ri (離, separar-se e criar caminho próprio). Tailoring pertence ao nível Ha; inventar processo do zero pertence ao Ri — nenhum dos dois deve ser tentado antes de dominar o Shu.
  • Como usar: antes de "customizar" uma prática ágil, pergunte honestamente se a equipe já praticou essa prática "pelo livro" o suficiente pra entender por que ela existe.
• Cuidado com pares autossuportados: muitas práticas ágeis funcionam em duplas que se sustentam mutuamente (ex. colocação física + requisitos leves; testes rígidos da XP + refatoração corajosa). Remover uma prática sem entender a que ela contrabalança tende a criar mais problema do que resolve.
• Ciclo de tailoring recomendado: encontrar a situação na Tabela X2-1 → ler a recomendação → discutir com quem será afetado → testar por 1-2 iterações (ou um período de fluxo) → avaliar em retrospectiva → institucionalizar só se funcionou.

Reference Table — Situações comuns e recomendações de tailoring

Situação	Recomendação-chave
Equipes muito grandes	Reestruturar em múltiplos projetos/equipes menores, releases mais frequentes com menos funcionalidades, reduzir a equipe aos membros essenciais, ou usar gerenciamento de programa ágil/Lean e frameworks de escala (DA, SAFe, LeSS) só se o esforço realmente exigir.
Equipes distribuídas	Ferramentas de comunicação (mensagens, videoconferência, quadros eletrônicos); reuniões presenciais antecipadas pra construir confiança; check-ins em rodízio pra compensar a perda de linguagem corporal; menos sincronização de projeto inteiro, mais encontros pequenos (2-3 pessoas) frequentes entre fusos horários distantes.
Produtos críticos de segurança/regulados	Ágil ainda serve, mas com camadas extras de revisão de conformidade, documentação e certificação — documentação pode virar parte do "pronto" de uma funcionalidade. Abordagem híbrida combinando rigor regulatório com colaboração ágil (exemplo citado: sistemas de controle de voo, farmacêuticas).
Requisitos estáveis + execução repetível	Questione se ágil é de fato necessário — baixa incerteza/risco pode não justificar o conjunto completo de práticas ágeis; considere estender a duração dos ciclos se eles não estiverem revelando/refinando requisitos de verdade.
Equipes em silos funcionais	Peça multifuncionalidade primeiro sem esperar aval da gestão e observe o que acontece; se o sistema de incentivos recompensa performance por área funcional (não por produto/equipe), mude isso primeiro — as pessoas dificilmente vão contra sua própria remuneração.
Transparência gera medo	Lidere pelo exemplo, mostrando decisões abertamente (quadro de status/quadro branco) — transparência exige coragem e se constrói modelando o comportamento, não exigindo dos outros.
Time com pouco conhecimento técnico de domínio	Não basta declarar "vamos usar ágil" e deixar um time inexperiente se autogerenciar — pode precisar de direcionamento adicional até adquirir habilidade, e centros de competência ajudam a suprir conhecimento de domínio.
Falta de engajamento executivo	Ache terreno comum nas necessidades reais da organização; use experimentos e retrospectivas pra progredir aos poucos; considere explicar ágil em termos de pensamento Lean (ciclos curtos, lotes pequenos) em vez do vocabulário ágil puro.
Vocabulário ágil não se encaixa na cultura	Troque os termos, mantendo o significado — se "jogo de planejamento" soa pouco profissional pra organização, chame de "workshop de planejamento". O nome importa menos que a atividade.

Anti-patterns

• Abandonar uma prática só porque foi "impopular" (o exemplo do texto: abandonar retrospectivas por impopularidade) — isso normalmente sinaliza um problema mais fundamental na equipe que o tailoring do método não resolve; abandonar a prática ainda piora a situação porque remove justamente a ferramenta de melhoria contínua.
• Fazer tailoring sem envolver quem será afetado: gera resistência mesmo quando a mudança é tecnicamente correta.
• Fazer tailoring antes de ter sucesso com a abordagem original: sem o nível Shu consolidado, não dá pra saber se o problema é a prática ou a execução da prática.

Key Takeaways

1. Regra de ouro do tailoring: só depois do sucesso com a abordagem "de manual" (Shu), sempre em colaboração, sempre testado antes de institucionalizado.
2. Antes de remover qualquer prática, pergunte o que ela contrabalança — práticas ágeis costumam vir em pares que se sustentam.
3. Use a Tabela X2-1 como primeiro recurso quando enfrentar uma das 9 situações comuns listadas — economiza reinventar a solução.
4. Mudar vocabulário pra caber na cultura organizacional é tailoring legítimo e de baixo risco — não é "diluir" o ágil, é torná-lo compreensível.

Connects To

• Cap 2: cita este apêndice diretamente ao alertar sobre os riscos do tailoring prematuro/descuidado.
• Cap 3 (Tabela 3-2): lista fatores de projeto que influenciam tailoring em nível mais resumido — este capítulo é o aprofundamento completo.
• Cap 5: o ciclo "testar → retrospectiva → institucionalizar ou abandonar" usado aqui é o mesmo ciclo de retrospectiva detalhado lá.