Não sou nem de longe um especialista em agile, mas têm algumas coisas no seu post que me soam estranhas:

O Agile sempre prometeu uma coisa: entregar código mais rápido.

Não acho que isso tenha sido uma promessa do manifesto ágil, os 12 princípios do manifesto são:

1. Garantir a satisfação do cliente, entregando rápida e continuamente software funcional;
2. Até mesmo mudanças tardias de escopo no projeto são bem-vindas;
3. Software funcional é entregue frequentemente (semanal ou mensal - o menor intervalo possível);
4. Cooperação constante entre as pessoas que entendem do 'negócio' e os desenvolvedores;
5. Projetos surgem por meio de indivíduos motivados, devendo existir uma relação de confiança;
6. A melhor forma de transmissão de informação entre desenvolvedores é através da conversa 'cara a cara';
7. Software funcional é a principal medida de progresso do projeto;
8. Novos recursos de software devem ser entregues constantemente. Clientes e desenvolvedores devem manter um ritmo até a conclusão do projeto;
9. Design do software deve prezar pela excelência técnica;
10. Simplicidade – a arte de maximizar a quantidade de trabalho que não é feito – é essencial;
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis;
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento

Veja que não há menção em entregar mais código e mais rápido, isso iria contra os princípios 9 e 10 por exemplo.

O que muita gente confunde, principalmente gestores, que ser ágil não é necessariamente ser rápido. No entanto, o esperado é entregar mais rápido e mantendo qualidade em comparação se não estivesse seguindo qualquer metodologia.

O Agile inteiro foi construído em cima de uma premissa que podia até fazer sentido: que o gargalo da entrega de software é a produção de código. Sprints, story points, velocity: tudo gira em torno de otimizar o throughput de código escrito por humanos.

Aqui é mais um ponto que me chama a atenção.

O que percebo é que o Agile tem sido usado como objetivo e não como metodologia ou processo, por exemplo, o problema não é ter sprints de 15 em 15 dias, o problema é fazer uma demanda de trabalho de 25 dias em uma sprint de 15, apenas pelo motivo que os gestores querem as sprints de 15 dias. Ou você ajusta o tamanho da demanda ou ajusta o tamanho da sprint.

Novamente, não sou especialista em Agile, mas tem outra coisa que quase toda empresa que diz seguir esses princípios faz é engatar uma sprint atrás da outra como se fosse uma linha de produção, vagões de um trem ou coisa assim, sem espaço entre elas, como se um período sem sprint é um período de projeto parado. Mas até onde li a respeito do Agile, não encontrei nenhuma orientação que as coisas precisam ser feitas dessa forma. Revisar e refatorar o projeto de tempos em tempos sem necessariamente mudar o resultado do software, mas deixar a manutenção e arquitetura mais simples também é uma forma de ser ágil.

Na minha visão, o Agile está focado na qualidade, na habilidade de mudar de direção rapidamente (por isso "ágil", "agilidade"), evitar passos para trás (retrabalho evitado com teste e integração contínua), satisfação do cliente, boa arquitetura, interação do time e etc. E a velocidade da entrega seria uma consequência de um trabalho organizado.

Mas como eu disse antes, quando se adota o Agile como meta as coisas tendem a não dar muito certo, vira burocracia, atrapalha o time, e os gestores veem sprints como uma forma de quantificar as entregas, quanto mais entregas em menos tempo melhor, aí sobe a pressão.

O problema foi quando o Agile transbordou dos times de desenvolvimento e caiu na graça dos gestores de produto e negócio.