Go Horse Sabor Ágil

A Ilusão da Velocidade: Uma Análise Exaustiva do Fenômeno “Go Horse Sabor Ágil” e a Falsa Sensação de Entrega no Desenvolvimento de Software Moderno

Introdução: O Paradoxo da Agilidade Contemporânea

No vasto e complexo ecossistema do desenvolvimento de software contemporâneo, a adoção de metodologias Ágeis transcendeu a categoria de “vantagem competitiva” para se tornar um imperativo de sobrevivência. Organizações de todos os portes, desde startups incipientes até conglomerados multinacionais, reestruturaram seus departamentos de tecnologia, derrubaram paredes de escritórios para criar espaços abertos, encheram as paredes de post-its coloridos e contrataram exércitos de Agile Coaches e Scrum Masters. A promessa era sedutora: maior velocidade, melhor adaptação às mudanças de mercado, transparência radical e, acima de tudo, a entrega contínua de valor ao cliente. No entanto, ao analisar a realidade operacional de muitas dessas equipes, emerge um fenômeno inquietante e paradoxal. Sob a fachada cerimonial do Scrum e do Kanban, reside uma prática antiga, caótica e profundamente enraizada na cultura de desenvolvimento, conhecida no vernáculo brasileiro como eXtreme Go Horse (XGH).

Este relatório, desenvolvido com o rigor de uma investigação técnica e sociológica, destina-se a dissecar a patologia organizacional que denominamos “Go Horse Sabor Ágil”. Este termo descreve a simbiose tóxica entre a anarquia operacional do XGH e a estrutura ritualística das metodologias Ágeis. O resultado dessa fusão não é a agilidade, mas sim um “Teatro do Ágil” ¹ — uma performance elaborada onde os atores (desenvolvedores, POs, gestores) seguem o roteiro das cerimônias, mas cujas ações nos bastidores são regidas pelo improviso, pela falta de qualidade e pela reatividade extrema.

O objetivo central desta análise é fornecer uma compreensão profunda sobre como o “Go Horse” se infiltra em ambientes supostamente ágeis sem ser percebido, criando uma “falsa sensação de entrega”. Investigaremos como métricas de vaidade, como a Velocity (velocidade), são manipuladas para mascarar a acumulação insustentável de dívida técnica e como a pressão por entregas constantes transforma Sprints em mini-cachoeiras (mini-waterfalls) de caos. Além disso, exploraremos as consequências devastadoras para a moral das equipes, a qualidade do produto e a viabilidade econômica das organizações a longo prazo.

A Evolução das Metodologias e a Persistência do Caos

Para compreender o “Go Horse Sabor Ágil”, é necessário revisitar a evolução das práticas de engenharia de software. O modelo Cascata (Waterfall), com suas fases rígidas e sequenciais, foi amplamente criticado por sua incapacidade de lidar com a incerteza. O Manifesto Ágil de 2001 surgiu como uma resposta, valorizando “indivíduos e interações mais que processos e ferramentas” e “software em funcionamento mais que documentação abrangente”. Contudo, a interpretação desses valores sofreu distorções severas.

No Brasil, e curiosamente com paralelos em outras culturas de engenharia (como o Cowboy Coding nos EUA), desenvolveu-se uma “anti-metodologia” satírica, mas dolorosamente real: o eXtreme Go Horse (XGH). Embora tratado como meme e piada em fóruns de tecnologia ⁴, o XGH codifica um comportamento padrão de “fazer agora, pensar depois”. A persistência do XGH não se deve à sua eficácia a longo prazo, mas à sua gratificação instantânea. Em um mercado viciado em velocidade, o XGH oferece a droga da entrega imediata, ainda que ilusória.

Quando organizações tentam adotar o Ágil sem mudar a cultura subjacente de “comando e controle” ou sem investir em excelência técnica, o XGH encontra um novo hospedeiro. Ele se veste com a terminologia do Ágil. O “fazer de qualquer jeito” passa a ser chamado de “MVP” (Minimum Viable Product). A falta de documentação é justificada como “software em funcionamento sobre documentação”. A ausência de planejamento é rebatizada de “responder a mudanças”. Assim, nasce o “Go Horse Sabor Ágil”: a desculpa perfeita para a incompetência gerencial e técnica, blindada pelo vocabulário irrefutável da modernidade.⁷

Parte I: Anatomia e Princípios do eXtreme Go Horse (XGH)

Antes de analisar a hibridização com o Ágil, é imperativo dissecar o XGH em sua forma pura. Os “axiomas” do XGH, embora escritos em tom humorístico, funcionam como dogmas operacionais em muitas equipes.⁴ A compreensão desses princípios é vital para identificar sua presença camuflada.

1. A Rejeição Cognitiva: “Penso, logo não é XGH”

O primeiro e mais fundamental axioma do XGH estabelece a primazia da ação sobre a reflexão: “Penso, logo não é XGH”.⁴ Na filosofia XGH, o tempo gasto pensando, planejando ou desenhando uma arquitetura é considerado desperdício (waste). A primeira ideia que surge à mente deve ser implementada imediatamente. Não existem segundas opções, pois a primeira é sempre a mais rápida.

Esta mentalidade é a antítese do empirismo Ágil, que prega a inspeção e adaptação. No entanto, em ambientes de alta pressão, esse axioma é frequentemente recompensado. O desenvolvedor que para para desenhar um diagrama de sequência é visto como “lento” ou “acadêmico”, enquanto aquele que começa a digitar código freneticamente é visto como “produtivo” e “pragmático”.¹⁰

2. A Trindade da Resolução de Problemas

O XGH postula que “Existem 3 formas de se resolver um problema: a correta, a errada e a XGH, que é igual à errada, só que mais rápida”.⁴ Este axioma revela a sedução econômica do XGH. A solução “correta” exige testes, refatoração, consideração de casos de borda e segurança. A solução “errada” falha. A solução XGH, por sua vez, parece funcionar no curto prazo e é entregue em tempo recorde.

A “falsa sensação de entrega” começa aqui. O stakeholder recebe a funcionalidade, vê-a operando no ambiente de demonstração e conclui que o trabalho foi concluído com sucesso. O que ele não vê são os atalhos: a falta de validação de dados, a consulta SQL vulnerável a injeção, o acoplamento rígido que impedirá mudanças futuras. A solução XGH é uma bomba-relógio embalada para presente.⁷

3. O Ciclo de Auto-Alimentação e a Entropia

“Quanto mais XGH você faz, mais precisará fazer”.⁴ Para cada problema resolvido com XGH, estima-se que sete novos problemas sejam criados. Isso gera uma dependência cíclica. Como o sistema se torna cada vez mais frágil e complexo (código espaguete), a única maneira de introduzir novas mudanças sem quebrar tudo ou levar meses analisando o impacto é… fazer mais XGH (gambiarras sobre gambiarras).

A utilidade do XGH tende ao infinito à medida que o projeto degrada. Em sistemas legados construídos sob essa égide, aplicar boas práticas de engenharia torna-se quase impossível sem uma reescrita total, forçando a equipe a continuar no modo de “sobrevivência” e “apagar incêndios” eternamente.

4. Reatividade Total e a Negação do Erro

“O XGH é totalmente reativo”.⁴ No XGH, erros só existem se alguém reclamar. Não há proatividade, monitoramento ou testes preventivos. A qualidade é definida pela ausência de gritos do cliente. Isso contrasta violentamente com o DevOps moderno, que busca shift-left (testar cedo) e observabilidade. No XGH, a equipe vive em um estado de “cegueira feliz” até o momento do colapso, quando então entra em modo de herói para salvar o dia.

5. O Caos como Estrutura

“O XGH é anárquico”.⁴ Padrões de projeto (Design Patterns), guias de estilo e convenções de nomenclatura são vistos como restrições à liberdade criativa do “cavalo louco”. A autenticidade do código XGH reside na sua ilegibilidade e na sua “criatividade” bizarra para contornar limitações técnicas através de “workarounds” (gambiarras).

Parte II: A Metamorfose: O Surgimento do “Go Horse Sabor Ágil”

A transição do XGH puro para o “Go Horse Sabor Ágil” ocorre quando uma organização adota os rituais do Ágil sem internalizar seus valores. Isso cria um ambiente de dissonância cognitiva, onde a linguagem é progressista, mas a prática é regressiva. Analisaremos como os pilares do Ágil são corrompidos por axiomas XGH, gerando o fenômeno conhecido como Zombie Scrum ou Agile Theater.

1. Scrum Zumbi: Rituais sem Alma

O Zombie Scrum descreve equipes que realizam todas as cerimônias — Daily Scrum, Sprint Planning, Sprint Review, Retrospective — mas não entregam incremento de software funcional e não têm intenção genuína de melhorar.¹³

• A Daily como Status Report: Em vez de um alinhamento tático para atingir a meta da Sprint, a Daily vira uma confissão de culpa ou um reporte burocrático para o Scrum Master. “Ontem fiz X, hoje farei Y, sem impedimentos” é recitado mecanicamente, enquanto, na realidade, o desenvolvedor está bloqueado por uma dívida técnica XGH que ele mesmo criou na semana anterior, mas tem medo de admitir.¹
• Retrospectivas de Lamentação: As retrospectivas, que deveriam ser motores de melhoria contínua (Kaizen), tornam-se sessões de terapia em grupo ou jogos de culpa (Blame Game). Problemas sistêmicos levantados (como a falta de testes) são ignorados pela gestão em favor de “mais velocidade”, validando o axioma XGH de que “não há refatoração, apenas retrabalho”.⁴
• Planejamento de Fantasia: O Sprint Planning ignora a capacidade histórica da equipe (Velocidade de Ontem) e aceita uma carga de trabalho imposta por desejos externos (Wishful Thinking). A equipe, condicionada pelo XGH a “prometer tudo”, aceita o escopo impossível, sabendo que usará atalhos (corte de qualidade) para “fingir” a entrega no final.¹⁶

2. A Corrupção dos Artefatos Ágeis

Artefato Ágil	Propósito Original	Versão “Go Horse Sabor Ágil”	Axioma XGH Relacionado
Sprint	Timebox protegido para foco e entrega de valor.	Prazo fatal e estressante (Crunch Time recorrente).	“O XGH não tem prazos… você sempre entregará a tempo.” 11
Backlog	Lista priorizada por valor e risco.	Lista de desejos desorganizada e fila de pedidos (Order Taking).	“O XGH é totalmente reativo.” 4
Definition of Done (DoD)	Critérios rigorosos de qualidade (testado, documentado).	Flexível: “Se compila, está pronto”. Testes são opcionais.	“Comite sempre… se compilar é lucro.” 7
MVP	Produto mínimo para aprendizado validado.	Desculpa para entregar código ruim e incompleto.	“A solução XGH é igual à errada, só que mais rápida.” 8
Estimativa	Previsão baseada em complexidade e incerteza.	Negociação de prazos; números inventados para agradar.	“Penso, logo não é XGH.” 4

3. Kanban e as Filas Infinitas

No Kanban, o princípio fundamental é “Limitar o Trabalho em Progresso” (WIP – Work In Progress). O “Go Horse Sabor Ágil” ignora isso completamente. As colunas de “Doing” ou “In Progress” tornam-se filas infinitas.¹⁸

A ausência de limites de WIP é uma manifestação direta da ansiedade gerencial e da mentalidade XGH de que “estar ocupado é ser produtivo”. Desenvolvedores alternam entre 5 ou 10 tarefas simultaneamente (context switching), o que destrói a produtividade e aumenta a taxa de erros. Visualmente, o quadro Kanban mostra muito movimento, criando a ilusão de atividade intensa, mas o Lead Time (tempo para uma tarefa atravessar o quadro) é altíssimo. As tarefas entram e ficam estagnadas, bloqueadas por dependências não resolvidas ou bugs, enquanto novas tarefas são empurradas para dentro do sistema.¹⁸

4. O Papel do Product Owner (PO) e Scrum Master (SM) no Teatro

Nesse cenário, os papéis também são distorcidos:

• O PO “Garçom”: Em vez de um visionário que maximiza valor e diz “não”, o PO torna-se um anotador de pedidos (Order Taker), repassando pressões de stakeholders diretamente para o time, sem filtro ou estratégia. Isso alimenta a reatividade do XGH.²
• O SM “Capataz”: O Scrum Master, em vez de um líder servidor que remove impedimentos, atua como um fiscal de Jira, cobrando atualizações de status e pressionando por velocidade, agindo como um cúmplice da cultura XGH.²

Parte III: A Falsa Sensação de Entrega e suas Mecânicas

A questão central solicitada é a “falsa sensação de entrega”. Como é possível que equipes pareçam estar entregando muito, sejam celebradas por sua velocidade, e ainda assim o produto esteja colapsando e o valor de negócio seja nulo?

1. A Armadilha da Velocidade (Velocity Trap)

A Velocity (pontos de história entregues por Sprint) é frequentemente usada como a métrica primária de sucesso no “Go Horse Sabor Ágil”. Isso cria um incentivo perverso. Para aumentar a velocidade, a equipe inflaciona as estimativas (Story Point Inflation) ou corta a qualidade.²³

No XGH Ágil, uma história de 8 pontos é entregue em 2 dias não porque a equipe foi eficiente, mas porque pulou os testes unitários, não fez revisão de código (Code Review) e ignorou os critérios de aceitação não-funcionais (como performance e segurança). O gráfico de Burndown parece perfeito, caindo suavemente até zero. A gestão aplaude. No entanto, essa “entrega” é um empréstimo de alto risco. A funcionalidade “está lá”, mas é frágil. A sensação de entrega é real para quem olha o gráfico, mas falsa para quem usa o sistema.

2. Dívida Técnica como Estratégia Oculta

A dívida técnica é a diferença entre o código que você escreveu (XGH) e o código que deveria ter escrito para ser sustentável. No “Go Horse Sabor Ágil”, a dívida técnica não é gerenciada; é ignorada. O axioma “não existe refactoring, apenas rework” ⁴ garante que o código nunca seja limpo.

Isso cria um fenômeno onde a velocidade de entrega inicial é altíssima (a fase “lua de mel” do projeto XGH), mas cai exponencialmente com o tempo. A falsa sensação de entrega ocorre porque, nas fases iniciais, o XGH realmente entrega mais rápido que o Ágil disciplinado. O Ágil investe tempo em infraestrutura de testes e design (investimento inicial). O XGH pula isso. O problema é que a curva do XGH atinge um muro. De repente, adicionar um simples campo num formulário leva três semanas porque o código é ininteligível. A organização, acostumada com a velocidade inicial (falsa), entra em pânico e pressiona por mais XGH, selando o destino do projeto.²⁶

3. A Fábrica de Features (Feature Factory)

O conceito de Feature Factory descreve organizações obcecadas com o Output (quantidade de coisas feitas) em vez do Outcome (resultado de negócio gerado).²⁹ O XGH é o motor perfeito para uma Fábrica de Features. Ele permite bombear funcionalidades em ritmo industrial, desde que ninguém se importe se elas funcionam bem ou se resolvem o problema do usuário.

A “falsa sensação de entrega” aqui é estratégica. A empresa acredita que está inovando porque lançou 50 novas features no ano. Mas se a taxa de retenção (Churn) de clientes é alta e a satisfação (NPS) é baixa, nada foi realmente entregue além de custo de manutenção. O XGH Ágil alimenta a métrica de vaidade “número de releases”, criando uma desconexão perigosa entre a TI e o Negócio.³⁰

4. Integração Contínua do Caos (CI/CD Theater)

Ferramentas modernas de CI/CD (Integração e Entrega Contínuas) são usadas no XGH Ágil para automatizar o desastre. O axioma “Comite sempre antes de dar update” ⁴ e “Se compila, comita” ⁷ incentiva o uso da pipeline de build como um testador de sorte. Desenvolvedores “bombardeiam” o repositório com código quebrado, esperando que o servidor aponte o erro.

A métrica de “deploys por dia” pode ser alta, o que parece DevOps avançado (Elite Performer). Mas se 30% desses deploys são hotfixes para corrigir o deploy anterior, e se a taxa de falha de mudança (Change Failure Rate) é alta, então a agilidade é uma ilusão. A equipe está apenas correndo em círculos muito rápido.

Parte IV: Impactos Humanos e Culturais: O Custo Invisível

Enquanto a “falsa sensação de entrega” afeta o produto, o impacto humano do “Go Horse Sabor Ágil” é visceral e destrutivo. A cultura organizacional é corroída silenciosamente.

1. A Cultura do Herói e o Bombeiro Piromaníaco

O XGH venera o herói. O desenvolvedor “Sênior XGH” é aquele que conhece todos os “macetes” e atalhos do sistema podre que ele mesmo ajudou a criar. Quando o sistema cai (o que é frequente, dado o axioma da reatividade), esse herói trabalha 24 horas seguidas, conserta o problema com um script mágico diretamente no banco de dados ⁵ e é aplaudido pela gestão como o “salvador da pátria”.

No Ágil saudável, o heroísmo é um sinal de falha no processo. No XGH Ágil, é o modelo de operação padrão. Isso cria a figura do “Bombeiro Piromaníaco”: o profissional que ganha prestígio apagando os incêndios que suas próprias práticas de má qualidade iniciaram.³³ Isso desmoraliza desenvolvedores disciplinados, que veem seu esforço em fazer o certo (testes, documentação) ser ignorado ou punido como “lentidão”, levando-os a sair da empresa (Brain Drain / Turnover).²²

2. Burnout e a Normalização do Sofrimento

A pressão constante para manter a velocidade ilusória do XGH, combinada com a imprevisibilidade de um sistema instável, leva inevitavelmente ao Burnout. A equipe vive em estado de alerta perpétuo. Sprints tornam-se maratonas de ansiedade. A frase “estamos em crunch time” deixa de ser uma exceção para virar a regra.

O axioma “Prepare-se para pular do barco quando ele começar a afundar” ⁴ reflete o cinismo que se instala. Os desenvolvedores sabem que o projeto é insustentável. Eles acumulam conquistas de curto prazo para o currículo e planejam sair antes do colapso inevitável, deixando a bomba para os sucessores.⁶

3. Neofobia e Resistência à Mudança

A persistência do XGH muitas vezes é alimentada pela neofobia (medo do novo).³⁵ Equipes e gestores acostumados com o caos sentem-se ameaçados pela transparência do Ágil real. O Ágil expõe a incompetência, mostra gargalos e exige responsabilidade. O XGH, com sua opacidade e mística de “complexidade técnica”, oferece um esconderijo seguro para a mediocridade. Adotar o “Agile Theater” é uma forma de defesa: finge-se mudar para que tudo permaneça igual.

Parte V: Diagnóstico e Indicadores Chave

Como identificar se sua organização está sofrendo de “Go Horse Sabor Ágil”? Abaixo, apresentamos um quadro comparativo de indicadores diagnósticos.

Dimensão	Ágil Autêntico	Go Horse Sabor Ágil
Planejamento da Sprint	Baseado na capacidade histórica (Velocidade de Ontem).	Baseado em prazos externos e desejos (Wishful Thinking).
Alteração de Escopo	Escopo da Sprint é protegido; trocas são negociadas.	Escopo é violado constantemente; “urgências” entram a qualquer hora (Scope Creep).
Qualidade (QA)	Integrada durante toda a Sprint (Shift Left).	Feita no final da Sprint ou pós-deploy; vista como gargalo.
Testes Automatizados	Essenciais, parte da Definition of Done.	Inexistentes ou quebrados; “não temos tempo para testes”.36
Refatoração	Contínua e encorajada (regra do escoteiro).	Proibida ou adiada para um futuro mítico (“Sprint de Hardening”).
Reação a Falhas	Post-mortem sem culpa, busca da causa raiz.	Caça às bruxas, busca de culpados e correções superficiais (Band-aid).
Atmosfera da Daily	Colaborativa, focada em resolver impedimentos.	Tenso reporte de status, foco em justificar o trabalho.
Visão do Produto	Focada em Outcome (Valor).	Focada em Output (Features) e Velocidade.

Parte VI: O Futuro e a Ameaça da IA no XGH

Um desenvolvimento recente e alarmante é a intersecção entre Inteligência Artificial Generativa (LLMs) e XGH, o que poderíamos chamar de XGH 2.0 ou AI-Augmented XGH.

Ferramentas como GitHub Copilot e ChatGPT permitem gerar grandes volumes de código rapidamente. Se usadas por uma equipe com mentalidade XGH (“Penso, logo não é XGH”), essas ferramentas agem como anabolizantes para a produção de código ruim. O desenvolvedor pode gerar uma função complexa em segundos, sem entender como ela funciona, e comitá-la imediatamente.³⁸

Isso acelera a criação da “Falsa Sensação de Entrega” de forma exponencial. A produtividade aparente dispara, mas a base de código torna-se um pântano de lógica gerada por máquina, difícil de depurar e manter. O risco é que o XGH assistido por IA crie sistemas de complexidade tal que nenhum humano consiga mais refatorar, levando a um evento de extinção técnica do produto muito mais rápido do que no passado.

Parte VII: Estratégias de Desintoxicação e Recuperação

Sair do ciclo do “Go Horse Sabor Ágil” exige coragem executiva e disciplina técnica. Não há bala de prata, mas há um caminho de reabilitação.

1. Quebrando o Ciclo da Reatividade

A organização deve, conscientemente, desacelerar para consertar. É preciso aceitar uma queda temporária na velocidade visível para pagar a dívida técnica. Isso exige que a liderança blinde a equipe contra novas features enquanto a estabilidade é restaurada.³⁹ A transição de “Apagar Incêndios” para “Prevenção de Incêndios” é o primeiro passo cultural crítico.

2. Imposição Radical de Limites (WIP e DoD)

• Limites de WIP: Devem ser impostos draconianamente. Começar menos para terminar mais. Se o quadro Kanban está cheio, ninguém puxa nova tarefa até que uma seja concluída. Isso força a colaboração (Swarming) para desbloquear o fluxo.¹⁸
• Definition of Done (DoD) Inviolável: A DoD deve incluir testes e code review. Se não está testado, não está pronto, não importa o quanto o gerente grite. O Scrum Master deve ter autonomia para bloquear releases que não cumpram a DoD.

3. Métricas de Valor sobre Métricas de Vaidade

Abandonar a obsessão pela Velocity e focar em Cycle Time (tempo total para entregar valor) e Lead Time. Monitorar a Change Failure Rate (taxa de falha) e o Mean Time to Recovery (tempo médio de recuperação). Essas métricas expõem a fragilidade do XGH, enquanto a velocidade a esconde.²⁵

4. Reeducação Técnica e Cultural

Investir em treinamento de práticas de engenharia como TDD (Test Driven Development), Pair Programming e Clean Code. Mas mais importante: valorizar comportamentos de qualidade. Promover e bonificar quem evita problemas, não quem heroicamente os resolve de madrugada. Desmantelar a cultura do herói é essencial para a saúde a longo prazo.⁴³

Conclusão: A Escolha entre Ser Ágil e Parecer Ágil

O fenômeno “Go Horse Sabor Ágil” é a doença crônica da indústria de software moderna. Ele prospera na lacuna entre a promessa do marketing Ágil e a realidade da disciplina de engenharia. Ele oferece um conforto sedutor: a sensação de movimento, a adrenalina da entrega rápida, a validação visual dos quadros cheios. Mas é uma ilusão. Uma “Falsa Sensação de Entrega” que hipoteca o futuro da empresa em troca de aplausos no presente.

Para o profissional que deseja publicar um artigo no LinkedIn sobre este tema, a mensagem central deve ser um chamado à honestidade intelectual. Reconhecer que estamos praticando XGH sob o manto do Scrum é doloroso, mas necessário. A verdadeira agilidade não é sobre fazer mais rápido; é sobre entregar valor de forma sustentável, adaptável e humana. Enquanto tratarmos a Sprint como uma corrida de cavalos (Go Horse) e não como um ciclo de aprendizado, continuaremos a construir castelos de cartas digitais, aguardando o sopro inevitável do colapso.

A cura começa quando a organização para de perguntar “Quando vai estar pronto?” e começa a perguntar “Qual valor estamos entregando e quão sustentável é esse ritmo?”. Só então o cavalo do XGH poderá ser aposentado, dando lugar à verdadeira agilidade.

Referências citadas

1. The Agile Paradox: When a Movement for Change Turns into a Religion (and How to Fix It) – Salt Technologies, acessado em fevereiro 4, 2026, https://www.salttechno.com/blog/the-agile-paradox-agile-theater-hybrid-software-delivery
2. Agile Theater: The Anti-Patterns Killing Your Transformation | by Panayiotis Kourouvanis, acessado em fevereiro 4, 2026, https://medium.com/@panayiotiskourouvanis/agile-theater-the-anti-patterns-killing-your-transformation-f03ecde73161
3. 10 Signs That Your Agile Transformation is NOT an “Agile Theater” – KSTS Consulting, acessado em fevereiro 4, 2026, https://www.keystepstosuccess.com/2025/06/10-signs-that-your-agile-transformation-is-not-an-agile-theater/
4. eXtreme Go Horse (XGH) : r/softwaredevelopment – Reddit, acessado em fevereiro 4, 2026, https://www.reddit.com/r/softwaredevelopment/comments/c7nj6l/extreme_go_horse_xgh/
5. MANIFESTO – Extreme Go Horse, acessado em fevereiro 4, 2026, https://www.extremegohorse.com.br/manifesto/
6. You Might Be Using eXtreme Go Horse Process and Not Even Know It – HackerNoon, acessado em fevereiro 4, 2026, https://hackernoon.com/you-might-be-using-extreme-go-horse-process-and-not-even-know-it
7. Learning from eXtreme Go Horse (XGH): A Wake-Up Call for Automated Agile – Medium, acessado em fevereiro 4, 2026, https://medium.com/@AgileChatGPT/learning-from-extreme-go-horse-xgh-a-wake-up-call-for-automated-agile-958237b81904
8. eXtreme Go Horse Methodology (XGH) | by Daniel Alonso – Medium, acessado em fevereiro 4, 2026, https://medium.com/@dekaah/22-axioms-of-the-extreme-go-horse-methodology-xgh-9fa739ab55b4
9. Agile is Dead, long live to Agile2! | by Pierre Tomasina | June 25, 2024 – plab.io, acessado em fevereiro 4, 2026, https://plab.io/blog/2024-06-25-agile-is-dead-long-live-agile2
10. eXtreme Go Horse (XGH) Design Methodology – Factorio Edition – Steam Community, acessado em fevereiro 4, 2026, https://steamcommunity.com/sharedfiles/filedetails/?id=2097096177
11. eXtreme Go-Horse Process – GitHub Gist, acessado em fevereiro 4, 2026, https://gist.github.com/banaslee/4147370
12. “eXtreme Go Horse” and Why Experienced Engineers Do Everything Wrong (TM) – YouTube, acessado em fevereiro 4, 2026, https://www.youtube.com/watch?v=30Ta8vKSppk
13. Zombie Scrum | Agile Academy Dictionary, acessado em fevereiro 4, 2026, https://www.agile-academy.com/en/agile-dictionary/zombie-scrum/
14. How A Culture Of Learning And Experimentation Can Prevent Zombie Scrum, acessado em fevereiro 4, 2026, https://www.scrum.org/resources/blog/how-culture-learning-and-experimentation-can-prevent-zombie-scrum
15. Fix Zombie Scrum in 3 Steps – Echometer, acessado em fevereiro 4, 2026, https://echometerapp.com/en/fix-zombie-scrum-in-3-steps/
16. 10 Symptoms Your Scrum Team is Broken, Part 1 – Rachael Wilterdink, acessado em fevereiro 4, 2026, https://rachaelwilterdink.com/10-symptoms-your-scrum-team-is-broken-part-1/2023/blogs-about-agile/
17. Should we take into account scope changes to the Sprint to measure the team efficiency?, acessado em fevereiro 4, 2026, https://pm.stackexchange.com/questions/34407/should-we-take-into-account-scope-changes-to-the-sprint-to-measure-the-team-effi
18. About Flows and Infinite Queues – Zsolt Fabók, acessado em fevereiro 4, 2026, https://zsoltfabok.com/blog/2013/04/infinite-queue/
19. When (if at all) is it okay to break the WIP limit? – Project Management Stack Exchange, acessado em fevereiro 4, 2026, https://pm.stackexchange.com/questions/11843/when-if-at-all-is-it-okay-to-break-the-wip-limit
20. Kanban and WIP limits : r/agile – Reddit, acessado em fevereiro 4, 2026, https://www.reddit.com/r/agile/comments/16k8sdh/kanban_and_wip_limits/
21. Not Every Scrum Team Is Agile: Fake Agile – Echometer, acessado em fevereiro 4, 2026, https://echometerapp.com/en/fake-agile-not-every-scrum-team-is-agile/
22. Agile Theatre: The Most Expensive Improv Show in Tech – The Cranky PM, acessado em fevereiro 4, 2026, https://www.thecrankypm.com/p/agile-implementation-fails-common-problems-solutions
23. Master Velocity: Your Secret to Sustainable Agile Success (and Common Pitfalls to Avoid!), acessado em fevereiro 4, 2026, https://ck.matthiasorgler.com/posts/master-velocity-your-secret-to-sustainable-agile-success-and-common-pitfalls-to-avoid
24. The Three Lies We Tell When Velocity Becomes the Goal | by Soumya | Agile True North | Jan, 2026 | Medium, acessado em fevereiro 4, 2026, https://medium.com/agile-true-north/the-three-lies-we-tell-when-velocity-becomes-the-goal-3180f7a8666d
25. Why Agile Velocity is the Most Dangerous Metric | LinearB Blog, acessado em fevereiro 4, 2026, https://linearb.io/blog/why-agile-velocity-is-the-most-dangerous-metric-for-software-development-teams
26. Technical Debt is a Systemic Problem – Agile Alliance, acessado em fevereiro 4, 2026, https://agilealliance.org/technical-debt-systemic-problem/
27. The surprising truth about technical debt in agile development – Devico.io, acessado em fevereiro 4, 2026, https://devico.io/blog/the-surprising-truth-about-technical-debt-in-agile-development
28. Say ‘bye’ to tech debt: Agile solutions for clean development – Atlassian, acessado em fevereiro 4, 2026, https://www.atlassian.com/agile/software-development/technical-debt
29. Feature factory or value vehicle? | Agile Cambridge, acessado em fevereiro 4, 2026, https://agilecambridge.net/programme/feature-factory-or-value-vehicle
30. Feature Factory vs. Value Factory: How to Escape the Shipping Trap | by Deeksha Agarwal, acessado em fevereiro 4, 2026, https://deekshagarwal.medium.com/feature-factory-vs-value-factory-how-to-escape-the-shipping-trap-998925fe7e73
31. Moving from Feature Factories to Value Generators – Itamar Gilad, acessado em fevereiro 4, 2026, https://itamargilad.com/feature-factory/
32. The Value Of The Feature Factory – Yuval Yeret, acessado em fevereiro 4, 2026, https://yuvalyeret.com/blog/product/agile-product-operating-model/the-value-of-the-feature-factory/
33. Hero Culture – Unconscious Agile, acessado em fevereiro 4, 2026, https://unconsciousagile.com/2023/11/18/hero-culture.html
34. Hero Culture or Crisis Culture? – TechWell, acessado em fevereiro 4, 2026, https://www.techwell.com/techwell-insights/2012/08/hero-culture-or-crisis-culture
35. 5 Minutes Podcast com Ricardo Vargas – FeedPress, acessado em fevereiro 4, 2026, https://feedpress.me/5pmpodcast_pt
36. 9 Common DevOps Antipatterns and How to Break them – CMC Global, acessado em fevereiro 4, 2026, https://cmc-apac.sg/it-insights/common-devops-antipatterns-to-avoid/
37. Testing Software Systems – SWI, acessado em fevereiro 4, 2026, https://swi.cs.vsb.cz/dam/jcr:94cf7ce0-b8e0-4f69-9353-5e157768c193/Testing%20and%20software%20Quolity%20EN.pdf
38. The future of AI-driven development isn’t Agile. It’s XGH. | by Pavel Samsonov | Medium, acessado em fevereiro 4, 2026, https://spavel.medium.com/the-future-of-ai-driven-development-isnt-agile-it-s-xgh-b4f6fbfe14f1
39. From Firefighting to Flow: Lessons Learned from a Project in Crisis | StickyMinds, acessado em fevereiro 4, 2026, https://www.stickyminds.com/article/firefighting-flow-lessons-learned-project-crisis
40. From Firefighting to Strategic Execution: 7 Frameworks That Actually Work – Doug Thorpe, acessado em fevereiro 4, 2026, https://dougthorpe.com/from-firefighting-to-strategic-execution-7-frameworks-that-actually-work/
41. How to succeed with WIP limits pt.2 | by Thorbjørn Sigberg – Medium, acessado em fevereiro 4, 2026, https://medium.com/@thorbjorn.sigberg/how-to-succeed-with-wip-limits-pt-2-4706581e10bd
42. Scrum Velocity: Six Things That Can Go Wrong – Qentelli, acessado em fevereiro 4, 2026, https://qentelli.com/products/thought-leadership/insights/scrum-velocity-six-things-can-go-wrong
43. How to break the cycle of firefighting – LeadDev, acessado em fevereiro 4, 2026, https://leaddev.com/management/how-break-cycle-firefighting
44. Eliminating hero culture in software engineering teams – Brianna McCollough | #LeadDevLive – YouTube, acessado em fevereiro 4, 2026, https://www.youtube.com/watch?v=aLEqgnQM0Xc
45. Preventing Hero Culture In Software Teams : r/programming – Reddit, acessado em fevereiro 4, 2026, https://www.reddit.com/r/programming/comments/sdlvxr/preventing_hero_culture_in_software_teams/