metodologias

24/10/2025

18min

Agile Não Funciona Fora do Desenvolvimento de Software e Talvez Nem Dentro Dele

Se você acha que Agile é "a única forma moderna de trabalhar", precisa explicar por que hospitais salvam mais vidas com checklists de 19 itens do que sua empresa entrega software com Scrum certificado. Precisa explicar por que aviões não caem seguindo waterfall pesado, enquanto seu app trava toda semana mesmo com daily standup. Precisa, principalmente, explicar por que o relatório PMI Pulse 2024 mostra desempenho idêntico entre times ágeis, híbridos e preditivos quando você controla pelo contexto do projeto.

A verdade brutal que ninguém quer admitir: Agile virou religião. E como toda religião, promete salvação mas entrega ritual vazio quando você não questiona os dogmas.

Vamos aos dados.

Por Que Construção Civil Ignora Suas Sprints (E Entrega Mesmo Assim)

A construção civil é o setor com menor adoção de práticas ágeis entre todas as indústrias — cerca de 27% segundo análises recentes do PMI. Não porque os engenheiros civis sejam dinossauros que não entendem "o futuro do trabalho". Mas porque eles constroem pontes que não podem cair.

Quando você erra uma sprint de software, refaz. Quando você erra o cálculo estrutural de uma viga, pessoas morrem e sua empresa vai à falência. Simples assim.

Mas aqui está o que vai irritar os agilistas de plantão: construção civil usa ciclos curtos e entrega incremental. Só que sem os teatrinhos.

Last Planner System: Compromisso Real vs. Story Points Imaginários

O Lean Construction desenvolveu o Last Planner System — uma abordagem que coloca responsáveis diretos fazendo promessas semanais sobre entregas concretas. Não "vou trabalhar em 13 pontos de estória". Mas sim "vou concretar 200m² do terceiro andar até sexta-feira, desde que o fornecedor entregue o material até terça".

A diferença? Eles medem o PPC — Percent Plan Complete. Você prometeu cinco coisas na semana. Entregou três. Seu PPC é 60%. Não tem emoji triste na retrospectiva, não tem "ah, mas foi por causa de impedimento". O número é o número.

Estudos publicados no Lean Construction Journal documentam aumentos médios de PPC de +12% e +14% em projetos reais que implementaram o sistema. Obras terminando antes do prazo. Orçamento respeitado. E nenhum planning poker foi necessário.

O que a construção faz de diferente? Três coisas que vão ferir sentimentos:

Primeiro: Promessa sem métrica é conversa de bar. Se você não consegue medir objetivamente se entregou o que prometeu, você não fez promessa — fez teatro.

Segundo: Gestão de restrições é mais importante que velocity. Quando o PPC cai, a equipe é forçada a identificar o que travou — fornecedor atrasou? Projeto mal especificado? Dependência com outra frente? — e resolver antes da próxima semana. Velocity não te diz isso. Só te diz que você está indo mais devagar, sem explicar por quê.

Terceiro: Ciclo curto sem qualidade definida é só caos acelerado. Cada entrega em construção tem critérios de aceitação baseados em normas técnicas (ABNT, por exemplo). Não é "o PO aceitou na demo". É "passou na inspeção estrutural segundo NBR 6118".

Agora me diga: seu time de software mede taxa de entrega real (features em produção vs. prometidas)? Tem gestão séria de dependências? Tem critérios de qualidade que alguém além do PO valida?

Não? Então talvez o problema não seja que construção é "tradicional demais". Talvez seja que software é indisciplinado demais.

Saúde: O Checklist Que Vale Mais Que Mil Retrospectivas

Em 2009, o cirurgião Atul Gawande liderou um estudo que humilha a indústria de software. Ele pegou um checklist de 19 itens — coisas estúpidas de tão óbvias como "confirmar o nome do paciente" e "verificar disponibilidade de sangue para transfusão" — e aplicou em oito hospitais ao redor do mundo.

As complicações cirúrgicas caíram de 11,0% para 7,0%. A mortalidade teve queda comparável. Publicado no New England Journal of Medicine, um dos periódicos médicos mais respeitados do planeta.

Dezenove itens. Zero Scrum Master. Zero sprint planning. Zero retrospectiva com post-its coloridos.

O Que Hospitais Sabem Que Você Não Sabe

Hospitais não "descobrem" como fazer cirurgia no meio do procedimento. Eles executam protocolos validados com pequenos ajustes baseados no contexto específico do paciente. A inovação não está em reinventar a roda toda semana — está em melhorar o protocolo com base em evidência acumulada ao longo de milhares de casos.

Quando um cirurgião cardíaco opera, ele segue guidelines da American Heart Association ou da Sociedade Brasileira de Cardiologia. Essas guidelines são atualizadas periodicamente com base em ensaios clínicos randomizados, meta-análises e revisão por pares. Não porque alguém "achou legal" na retrospectiva.

O paralelo com software deveria ser óbvio, mas vou explicar porque aparentemente não é:

Sua "Definição de Pronto" deveria ser um checklist. Curto. Objetivo. Impossível de interpretar de duas formas diferentes. Por exemplo:

Testes unitários com cobertura mínima de 80% em lógica de negócio
Revisão de código aprovada por pelo menos um desenvolvedor sênior
Deploy bem-sucedido em ambiente de homologação
Documentação atualizada (README, CHANGELOG, diagrama de arquitetura se houver mudança estrutural)
Rollback testado e funcional

Cinco itens. Se qualquer um faltar, não está pronto. Não interessa se o PO "aceitou" na demo, não interessa se a sprint está acabando, não interessa se o VP de produto está cobrando entrega.

Não está pronto.

Mas não é isso que acontece na maioria dos times, certo? O que acontece é: acabou a sprint, "entregamos" oito de dez stories, duas ficaram em "done done done" (código escrito mas sem teste, sem revisão, com bug conhecido que "a gente arruma depois"), e na próxima planning ninguém menciona essas duas porque já estão em outras prioridades.

Hospitais não fazem isso. Sabe por quê? Porque o paciente morre se você deixar "arruma depois".

No seu software, o paciente é o usuário. E sim, você está matando ele — só que aos poucos, com mil pequenos bugs, com performance horrível, com experiência frustante. Mas como ele não morre literalmente, você chama de "débito técnico" e segue para a próxima sprint.

Aviação e Automotivo: Onde Compliance Esmaga Cerimônia

Você já voou. Sua vida dependeu de software certificado pela DO-178C — o padrão que rege sistemas embarcados em aviação. Esse documento não é sugestão corporativa que você ignora quando o deadline aperta. É requisito legal auditado por autoridades aeronáuticas.

A DO-178C exige:

Rastreabilidade completa requisito → código → teste
Cobertura estrutural verificada (MC/DC para código crítico)
Qualificação de ferramentas (até o compilador precisa ser validado)
Evidência documental de cada fase
Revisão independente de tudo

Não existe "trust me bro, funciona" em software aviônico. Não existe "a gente testa em produção" quando produção é 10.000 metros de altitude com 300 pessoas a bordo.

O Custo Real do "Fail Fast"

A indústria de software adora o mantra "fail fast, learn fast". É bonito no slide do keynote. É desastroso quando aplicado sem contexto.

No automotivo, a ISO 26262 rege desenvolvimento de sistemas eletrônicos críticos de segurança. Freio ABS, controle de estabilidade, airbag — tudo passa por um processo rigoroso baseado no modelo V:

Requisitos de sistema (topo do V)
Requisitos de software
Arquitetura de software
Implementação (fundo do V)
Testes unitários
Testes de integração
Testes de sistema
Validação (topo do outro lado do V)

Cada fase tem gates de qualidade com critérios objetivos. Você não "passa para a próxima" porque acabou a sprint. Você passa quando a evidência comprova que os requisitos de segurança foram atendidos.

Montadoras trabalham com iterações? Sim. Mas essas iterações estão subordinadas à estrutura de verificação exigida pela norma. Você pode fazer dez sprints para desenvolver o algoritmo de controle de tração — mas cada sprint precisa manter a rastreabilidade, executar os testes de regressão e documentar as mudanças.

A diferença para o Scrum comum? A definição de done é ditada por uma norma internacional, não pelo capricho do time.

E sabe qual é a parte que dói? Aviação e automotivo entregam software mais confiável que a maioria das startups. Com menos bugs. Com menos incidentes. Com menos "desculpa, foi mal, vamos corrigir na próxima release".

Não porque eles são mais inteligentes. Mas porque o custo do erro força disciplina.

Marketing Digital: A Adoção Que Ninguém Te Conta Direito

A narrativa oficial: "Marketing também virou ágil! Quadros Kanban, sprints de campanha, todo mundo colaborando!"

A realidade: Marketing pegou os pedaços que servem e ignorou o resto.

Segundo pesquisa da AgileSherpas 2024, 86% das organizações de marketing planejam expandir times ágeis, e 94% relatam apoio organizacional. Os números parecem ótimos até você ler as entrelinhas.

O Híbrido Que Ninguém Chama de Híbrido

Campanhas têm deadlines fixos. Black Friday não espera sua sprint acabar. Lançamento de produto alinhado com evento global não pode ser "reprioritizado" porque surgiu item mais urgente no backlog.

Compliance legal em publicidade não negocia. Se sua peça precisa passar por aprovação jurídica (e a maioria precisa, especialmente em setores regulados como farmacêutico, financeiro, alimentos), você não pode simplesmente "iterar baseado em feedback". O feedback que importa vem do advogado, e ele não aceita "a gente melhora na próxima sprint".

O que marketing realmente faz:

Usa quadro visual para organizar trabalho — mas com swimlanes separadas para "aguardando aprovação legal", "aguardando fornecedor", "bloqueado por diretrizes de marca".

Faz reuniões rápidas — mas não elimina as reuniões de alinhamento com stakeholders externos (agência, fornecedores, parceiros de mídia) que têm suas próprias agendas.

Trabalha em ciclos — mas esses ciclos terminam em marcos duros que foram definidos meses antes: lançamento em feira de setor, campanha sazonal, sincronização com calendário comercial.

É híbrido por necessidade. E funciona melhor que o Scrum puro funcionaria, porque respeita as restrições reais do negócio em vez de fingir que elas não existem.

A lição que a indústria de software deveria aprender: adaptação inteligente vence pureza metodológica. Todo santo dia.

O Que o PMI 2024 Revelou (E Ninguém Quer Admitir)

O relatório Pulse of the Profession 2024 do Project Management Institute jogou água fria na fogueira do hype ágil. A conclusão central, baseada em milhares de projetos ao redor do mundo:

Desempenho é comparável entre abordagens ágil, híbrida e preditiva quando você controla por contexto.

Leia de novo. Devagar.

Não importa se você usa Scrum, Kanban, Waterfall ou um híbrido inventado pelo seu time. O que importa é adequação ao contexto:

Custo de mudança no seu domínio
Nível de certeza sobre requisitos
Criticidade de erro
Necessidade regulatória
Complexidade de coordenação
Maturidade da equipe

Quando você escolhe método antes de entender contexto, você está fazendo astrologia corporativa. "Somos ágeis porque 2024" não é estratégia — é superstição.

A Métrica Que Deveria Importar (Mas Não Importa)

O PMI mede sucesso por três dimensões principais:

Entrega no prazo e orçamento
Qualidade e satisfação do cliente
Alcance dos objetivos de negócio

Não mede quantas cerimônias você faz. Não mede se você usa Fibonacci ou t-shirt sizing. Não mede se seu Scrum Master tem certificação.

E quando você olha os dados cruzados, uma verdade inconveniente aparece: times que executam bem qualquer método superam times que executam mal o método "certo".

Um time com Waterfall disciplinado — requisitos claros, arquitetura pensada, testes rigorosos, gestão ativa de risco — entrega melhor que um time com Scrum bagunçado onde planning vira sessão de adivinhação e retrospectiva vira terapia em grupo.

O problema nunca foi a metodologia. Foi a execução mediocre mascarada por jargão moderno.

Os Princípios Que Sobrevivem (Quando Você Para de Fingir)

Tira as cerimônias. Tira o jargão. Tira a certificação cara que te ensinou a facilitar retrospectiva. O que sobra?

1. Qualidade Não Se Negocia

Hospitais têm checklist. Aviação tem DO-178C. Construção tem normas ABNT. Automotivo tem ISO 26262.

Software tem... o quê? "A gente testa em produção e monitora com Datadog"?

Definição de Pronto deve vir antes do trabalho começar. E deve ser objetiva o suficiente para que dois desenvolvedores diferentes, olhando o mesmo código, cheguem à mesma conclusão sobre se está ou não pronto.

Se sua DoD é "código funciona e PO aceitou", você não tem padrão de qualidade. Você tem teatro.

2. Compromisso Sem Medição É Mentira

O Last Planner System funciona porque mede promessa contra entrega: PPC.

Seu time mede isso? Ou mede velocity — uma métrica interna que não diz absolutamente nada sobre se você entregou o que prometeu ao cliente?

Velocity te diz que você queimou 40 pontos nessa sprint. Ótimo. Quantas features foram para produção? Quantos bugs críticos foram fechados? Quantos usuários foram impactados positivamente?

Se você não sabe responder essas perguntas sem consultar três ferramentas diferentes, seu sistema de medição está otimizando a métrica errada.

3. Rastreabilidade É Proteção, Não Burocracia

Você não precisa da burocracia completa da DO-178C. Mas precisa conseguir responder:

Qual requisito esse código implementa?
Quais testes verificam esse requisito?
Quem aprovou essa mudança?
Por que tomamos essa decisão de arquitetura?

Quando você não consegue responder essas perguntas seis meses depois, paga o preço em:

Retrabalho (porque ninguém lembra por que foi feito daquele jeito)
Bugs de regressão (porque ninguém sabia que aquele código dependia daquela condição)
Decisões ruins repetidas (porque ninguém documentou por que a primeira tentativa falhou)

Rastreabilidade leve — um link do ticket para o PR, um comentário explicando o contexto, um diagrama de arquitetura atualizado — economiza tempo. Não desperdiça.

4. Cadência Sem Entrega É Ilusão de Progresso

Você pode fazer daily todo dia, planning toda segunda, review toda sexta e retrospectiva alternada.

Se no final do mês nada foi para produção, você não tem cadência de entrega. Tem cadência de reunião.

Lean Construction ensina: ciclo curto só funciona se produz saída concreta. Não "história pronta". Não "código escrito". Mas valor entregue segundo algum critério objetivo.

No software, isso significa: código em produção, acessível a usuários, resolvendo problema real, com qualidade verificável.

Todo o resto é vanity metric.

O Roteiro Brutal Para Quem Quer Resultado Real

Chega de filosofia. Vamos ao operacional.

Semana 1: Destrua Sua Definição de Pronto Atual

Sério. Pegue sua DoD e jogue fora. Ela provavelmente é vaga ("código de qualidade", "testes adequados"), cheia de exceções ("pode pular revisão se for urgente") e ninguém segue de verdade.

Reescreva com cinco critérios objetivos e verificáveis:

Cobertura de teste mínima (número, não "adequado")
Revisão de código aprovada (por quem? em quanto tempo?)
Deploy em homologação bem-sucedido (100% automatizado ou tem etapa manual?)
Documentação atualizada (quais artefatos exatamente?)
Rollback testado (você já tentou reverter? funciona?)

Se um critério não pode ser verificado por alguém novo no time sem ajuda, reescreva até poder.

Semana 2-4: Meça Promessa vs. Entrega

Pare de medir velocity. Comece a medir taxa de entrega:

Início da semana: time lista o que vai colocar em produção
Fim da semana: contabiliza o que realmente foi
Taxa = entregue ÷ prometido × 100

Se a taxa ficar abaixo de 70% por duas semanas seguidas, pare tudo e faça análise de restrições:

O que travou cada item?
Dependência externa? Requisito mal escrito? Infra não pronta? Dívida técnica?
Ação concreta para remover a restrição mais frequente

Isso é gestão. O resto é conversa.

Mês 2: Implemente Rastreabilidade Mínima

Todo ticket tem três campos obrigatórios antes de entrar em desenvolvimento:

Contexto: Por que estamos fazendo isso? (1-2 parágrafos)
Critério de aceite: Como sabemos que funcionou? (lista objetiva)
Testes esperados: Que testes esse código deve ter?

Todo PR tem:

Link para o ticket
Descrição de o que mudou e por que mudou assim
Evidência de teste (screenshot, log, output de test runner)

Se alguém novo lê o PR seis meses depois e não entende o contexto, o PR está mal escrito.

Mês 3: Checklist Crítico Para Momentos de Risco

Identifique seus três momentos de maior risco. Provavelmente:

Deploy em produção
Rollback de emergência
Revisão de feature grande

Crie checklist curto (máximo 10 itens) para cada:

Deploy:

Variáveis de ambiente conferidas em produção?
Migrações de banco rodadas e verificadas?
Feature flags configuradas corretamente?
Monitoramento específico configurado?
Plano de rollback documentado e testado?

Rollback:

Versão anterior identificada?
Dados em risco de perda? (backup feito?)
Comunicação para stakeholders enviada?
Postmortem agendado em até 48h?

Execute o checklist toda vez. Sem exceção. Audite na retrospectiva quantas vezes pularam item.

Mês 4-6: Padronize Decisões Técnicas

Toda decisão arquitetural importante vira documento de uma página:

Contexto: Qual problema estamos resolvendo?
Opções consideradas: Quais alternativas avaliamos? (mínimo três)
Decisão: O que escolhemos e por quê?
Consequências: Que trade-offs aceitamos?

Formato: ADR (Architecture Decision Record). Armazene no repositório, versionado com código.

Quando alguém questionar "por que fizemos assim?" seis meses depois, você tem resposta documentada. Ou descobre que a razão não existe mais e está na hora de mudar.

Os Sinais de Que Você Está Fazendo Teatro

Você diz que é "ágil", mas:

Sprint termina com história "quase pronta" que vira dívida técnica na próxima
Velocity é a métrica principal, mas ninguém sabe quantas features foram para produção
Planning dura 4 horas porque ninguém preparou nada e estão descobrindo requisitos na hora
Retrospectiva vira reclamação sem ação concreta depois
Daily vira status report com todo mundo olhando para o Scrum Master em vez de coordenar entre si
DoD tem exceção para "quando é urgente"
Technical debt é aceito como normal em vez de tratado como emergência
Ninguém consegue explicar por que aquele pedaço de código existe

Se você reconheceu quatro ou mais itens, parabéns: você não tem processo ágil. Tem cargo cult.

Está fazendo as dancinhas, mas não entende por que a chuva não vem.

O Contraexemplo Que Confirma a Regra

Vai sempre ter alguém dizendo: "Ah, mas eu conheço um hospital que usa sprints" ou "empresa X de hardware trabalha ágil e dá certo".

Ótimo. Olhe os detalhes.

Quando healthtech usa sprints para desenvolver software de prontuário eletrônico, ainda precisa atender HIPAA (nos EUA) ou LGPD (no Brasil) + normas específicas de saúde. As sprints existem, mas com compliance não-negociável em cima.

Quando hardware faz "desenvolvimento ágil" de dispositivo médico, ainda precisa passar por certificação FDA ou Anvisa. Tem prototipagem rápida? Sim. Mas cada iteração mantém rastreabilidade exigida pela IEC 62304 (software de dispositivo médico).

A sprint é a ferramenta. A norma é o chão.

O erro de quem "copia o exemplo" é achar que pode ter a sprint sem o chão. Não pode. A sprint sem estrutura embaixo vira caos bonito.

A Verdade Desconfortável Sobre Software

Software é a indústria com menor custo de erro visível entre todas as que discutimos.

Se o cirurgião erra, paciente morre na mesa.

Se o engenheiro civil erra, prédio cai.

Se o software de avião falha, 300 pessoas morrem.

Se seu app trava, o usuário... reclama no Twitter e continua usando porque não tem alternativa decente.

Essa diferença de consequência criou uma cultura de mediocridade aceita. "A gente conserta depois" vira operação padrão. "Dívida técnica" vira eufemismo para "código mal feito que não queremos arrumar".

E Agile — que nasceu como reação contra planejamento excessivo e documentação inútil — virou desculpa para não ter planejamento nenhum e não documentar nada.

"Somos ágeis" passou a significar "não preciso pensar antes de codificar, não preciso documentar decisões, não preciso manter qualidade porque a gente itera".

Não era para ser assim.

Os autores originais do Manifesto Ágil eram desenvolvedores experientes que sofreram com processos burocráticos em empresas grandes. Eles tinham a disciplina internalizada — só queriam menos processo externo atrapalhando.

O que aconteceu foi: todo mundo pegou a parte do "menos processo" e ignorou a parte da "disciplina internalizada".

Resultado: geração inteira de desenvolvedores que acha que qualidade é opcional, que documentação é coisa de dinossauro, que pensar na arquitetura antes de codificar é "waterfall".

O Que Fazer Quando Sua Empresa Já Está Doente

Se você está lendo isso e reconhecendo a empresa onde trabalha, aqui vai o plano de sobrevivência:

Nível Individual (O Que Você Controla)

Documente suas próprias decisões. Não espere o time fazer. Todo PR que você abre, toda feature que você implementa, deixa contexto escrito. Seu "eu do futuro" vai agradecer.

Mantenha padrão pessoal de qualidade. Mesmo se o time aceita código sem teste, você não aceita no seu PR. Mesmo se ninguém faz revisão decente, você faz.

Meça sua própria taxa de entrega. Segunda-feira: lista o que vai colocar em produção essa semana. Sexta: verifica o que entregou. Honestamente.

Se a taxa fica baixa, investiga por quê. Se é porque você está sendo interrompido por bugs, escreve isso. Se é porque requisitos são uma bagunça, documenta exemplos. Dados vencem opinião.

Nível Time (Se Você Tem Influência)

Proponha experimento de um mês: "Vamos medir taxa de entrega (prometido vs. entregue em produção) durante um mês. Só medir, sem julgamento. Depois discutimos o que aprendemos."

A resistência virá. "Velocity já mede isso" (não mede). "Isso vai criar pressão" (pressão já existe, só está invisível). "A gente já entrega bem" (se entrega bem, o número vai mostrar).

Insista no experimento temporal. Um mês. Sem mudança em nada, só medir diferente.

Os dados vão falar por si.

Implemente checklist de deploy. Não precisa de aprovação do Agile Coach. Crie o checklist, use você mesmo, compartilhe com quem se interessar. Se funciona (e vai funcionar), outros adotam naturalmente.

Escreva ADRs para suas decisões técnicas. Mesmo que ninguém mais faça. O repositório está lá, começe a povoar. Templates prontos existem (procure "ADR template" ou "MADR - Markdown ADR").

Nível Organização (Se Você É Lead/Manager)

Mude a métrica principal de velocity para outcome. Pare de perguntar "quantos pontos queimamos?" e comece a perguntar "quantos usuários foram impactados? qual problema resolvemos?"

Reescreva DoD coletivamente, mas com critérios objetivos. Sessão de uma hora, todo mundo junto, resultado documentado e afixado onde todos veem.

Institua revisão mensal de dívida técnica. Não retrospectiva de sprint — reunião específica onde se decide: que dívida vamos pagar esse mês? Quanto tempo reservamos? Quem faz?

Trate dívida técnica como emergência de saúde pública do código, não como "lista de coisas que seria legal fazer um dia".

Treinamento não é sobre Scrum. É sobre engenharia. Code review efetivo. Arquitetura de software. Testes automatizados. Gestão de dependências. Deploy seguro.

As cerimônias qualquer um aprende em dois dias. Engenharia de software leva anos.

Por Que Esse Artigo Vai Irritar Gente

Se você chegou até aqui sentindo desconforto, raiva ou vontade de digitar uma refutação furiosa nos comentários, bom.

Significa que acertei o alvo.

A indústria de software construiu uma bolha de conforto onde questionar Agile é heresia. Onde sugerir que documentação pode ser útil te marca como "dinossauro". Onde defender que planejamento antecipado reduz retrabalho te faz "inimigo da agilidade".

Essa bolha precisa estourar.

Não porque Agile seja intrinsecamente ruim. Mas porque a implementação medíocre mascarada por jargão moderno está produzindo software pior, não melhor.

Hospitais salvam vidas com checklist de 19 itens.

Construção entrega obras no prazo com promessas semanais medidas.

Aviação mantém você vivo com compliance brutal.

Enquanto isso, sua empresa faz daily, planning, review, retrospectiva — e entrega software que trava, vaza dados e frustra usuários.

O problema não é a metodologia. É a execução sem princípios.

Conclusão: Traduza, Não Copie

Agile não falhou fora do software porque "outras indústrias são atrasadas".

Falhou porque o pacote fechado de cerimônias não resolve os problemas fundamentais desses setores: risco regulatório, custo físico do erro, cadeias longas de fornecimento.

O que funciona universalmente:

Padrão de qualidade explícito e verificável (checklist, norma, DoD objetiva)
Compromisso mensurável de curto prazo (PPC, taxa de entrega, não velocity)
Rastreabilidade leve mas rigorosa (requisito → código → teste → evidência)
Gestão ativa de restrições (o que travou? como removemos?)

Traduza esses princípios para seu contexto. Não copie as cerimônias.

Se você trabalha com software, pergunte:

Meu DoD é objetivo o suficiente para um júnior aplicar sem ajuda?
Eu sei, agora, quantas features foram para produção no último mês?
Eu consigo rastrear de requisito até código até teste para qualquer mudança recente?
Quando algo trava, eu identifico e removo a restrição ou só "escalo com stakeholder"?

Se a resposta para duas ou mais é "não", seu problema não é escolher Scrum vs. Kanban.

É falta de disciplina de engenharia disfarçada de "cultura ágil".

E nenhuma certificação de Scrum Master vai resolver isso.

Este artigo não é contra Agile. É contra a versão cargo cult de Agile que virou padrão na indústria — onde todo mundo faz as cerimônias mas ninguém mantém a disciplina de engenharia que faz software funcionar. Se você ficou incomodado, ótimo. Agora faça algo com esse desconforto.