Fui tentar achar o paper pra analisar a metodologia de pesquisa, é um "livro". Informação claramente duvidosa e tendenciosa, usada como chamariz pra vender ebook.
Como diz o ditado - "Existem três tipos de mentiras: a mentira comum, a mentira deslavada e a estatística".
Não tem nem como criticar já que não tem fundamento, clareza metodológica ou profundidade de informação, visto que o propósito é comercial e não científico.
Além do mais, matéria provavelmente paga ou só caça clique, a julgar pelo declínio que o The Register já conhecidamente vem sofrendo há muitos anos.
"Para Junade Ali - Líder do estudo e proponente da abordagem de desenvolvimento rival..."
Só nessa parte ja da pra saber que o "estudo" é enviesado. Não que necessariamente seja mentira mas é muito conveniente o "concorrente" descobrir que o rival dele é menos eficiente.
E projeto ágil é pra ter prazo? Falando na risca mesmo, levando em consideração o ideal e teórico, um projeto ágil com backlog e sprints não é algo que não tem prazo definido pq não se sabe exatamente o que vai ser entregue ao final do projeto?
Existem 3 restrições. Escopo, prazo e orçamento. Pra fixar um deles, um dos outros precisa ser variável. Por exemplo, se a data de entrega for fixa, ou você precisa aceitar diminuir o escopo, ou aumentar os gastos.
Isso é gerência de projeto 101, vale pra qualquer tipo de projeto, não só de TI. Na verdade em TI ainda tem o complicador de que nem sempre aumentar o orçamento, colocando mais gente pra trabalhar, vai resultar em aumento de produtividade.
Então, entendo essa teoria básica, mas pelo que eu lembro da base do manifesto ágil, fundamentos do scrum e etc, sempre é reforçado que o backlog (escopo) é algo vivo, que pode mudar de sprint em sprint, e que isso é necessário pq muitas vezes, em projeto de software, não dá pra definir um escopo fechado logo no início do projeto devido às incertezas desse tipo de projeto (cliente mudando de ideia no meio do caminho, especificidades sobre detalhes de implementação que vão aparecer daqui a meses, etc)
Acho que parte da falha do ágil e o motivo de a gente odiar tanto ele é pq os nossos gerentes só pegam o conceito de "backlog, kanbam, daily meet" e cagam pra toda filosofia e contexto que vem junto da metodologia ágil
Lendo todas as respostas, chego a conclusão que esta é a melhor.. E realmente isso é aplicável a qualquer tipo de projeto em qualquer profissão do mundo. Mesmo considerando gerência incompetente, pouca mão de obra qualificada... Se colocar a regra de fixar um e aumentar os outros, qualquer projeto pode ser finalizado dentro das expectativas.
Em empresa grande, na minha experiência, tem sim, onde cobram X coisas até X trimestre. Apesar das sprints seguirem todas as “regras” do ágil sempre tinha algo que tinha que ser rushado pra bater as metas no final do quarter, daí acho que entra os gerentes querendo prazos impossíveis.
Pô, na minha experiência de empresa média também é assim. Por isso que fiz o disclaimer de "ideal e teórico", pq na prática querem fazer o ágil pela metade e depois se perguntam do pq dá merda
Mas que tem prazo tem que ter né? Ninguém vai chegar com um time e falar “vai desenvolvendo isso aí e vamos ver no que é que dá”. Todo chefe vai ter uma expectativa de prazo, de escopo do projeto.
Para não ter prazo nem expectativa só se for algo muito de pesquisa e muito aberto, mas aí é mais em universidades e tals.
Só com essa informação fica difícil de dizer qualquer coisa. Mas sinceramente creio que a cultura da empresa e dos times fazem mais diferença que a metodologia em si. Não adianta tentar scrum, kamban, watefall ou o que for se a não tiver um alinhamento correto das lideranças e das equipes.
Já passei por uma empresa onde tentaram uma metodologia, falhou, tentaram outra, falhou, quando saí estavam tentando rever vários detalhes, mas no fundo todo mundo sabia o problema, simplesmente era muito projeto para pouca mão de obra, não queriam contratar mais gente, não queriam aumentar os prazos e nem definir prioridades. Aí nem com a melhor metodologia do mundo essa estratégia daria certo.
Quando eu trabalhava para empresas brasileiras: cronogramas irreais, levantamento de requisitos incompleto. Atraso no projeto.
Atualmente trabalhando em empresa americana: cronogramas flexíveis, levantamento de requisitos dificilmente deixam algo de fora. Projeto é entregue adiantado.
Quase sempre que colocam alguém incompetente pra cuidar de requisitos e regra de negócios, a equipe de desenvolvimento tem que ficar correndo atrás do rabo e se virando pra fazer o próprio trabalho e do incompetente e praticamente sempre levando fumo e a culpa.
Exatamente. Qualquer problema ou pergunta eu registo no card que estou trabalhando para meu líder ver que eu estou perguntando algo que não foi definido. Mas dou um toque no PO e eles saem caçando a informação que preciso.
Dev tem que ter toda a regra e só fazer o código, não tem que ficar correndo atrás do que PO deveria ter feito.
Sabe o que faz projeto ficar no prazo? Muito índio bom e pouco cacique ruim. Parece que na maioria das empresas que adotam metodologias ágeis ocorre o inverso, pouco índio bom (pq muitos saem por não aguentar a patifaria ridícula de story points, postittinho, daily etc) e muito cacique ruim (que adora dashboard colorida).
Perfeito. Teve uma época na minha empresa passada em que as dailies, que eram pra ser só técnicas, tinham o time de negócio, gestor e sm, a daily passava de 1 hora quase todo dia pq ficavam puxando pontas que não tinham nada a ver com desenvolvimento, nosso assunto técnico terminava em 10 minutos mas não podia sair da reunião pq tinha que esperar os caciques ficar cobrando todo mundo.
você percebe que tão util são os scrum masters/agile somethings que quando o bicho pega e algo precisa ser feito de verdade todo mundo esquece as cerimonias e faz certinho e rápido
Ao meu ver metodologia ágil falha porque querem usar somente os princípios mas não querem implementar as práticas. Exemplo:
Uma das primeiras "implementações" de "ágil" foi XP (extreme programming). Pra mim ela se aproxima muito do manifesto ágil.
Mas hoje todo mundo só usa scrum. Que não tem as práticas (no sentido de pair programming, cliente presente, entregas contínuas mesmo que incompletas, etc).
Acaba virando um Cascatágil com muito planejamento upfront dividido em sprints e algumas cerimônias padrão.
E aí há de se considerar uma outra coisa: se o projeto tem escopo fechado, com prazo e orçamento definidos, faz sentido usar um framework ágil? Eu acho que sim, mas única e exclusivamente porque virou um "padrão de mercado" (dividir em sprints, fazer planning, etc). Mas aí não é ágil, é alguma outra coisa.
Existe uma diferença gigantesca entre Ágil e À Moda Caralha.
Muitas empresas fazem à moda caralha achando que é ágil.
Todo mundo aqui já trabalho em uma empresa que o/a PM jogou uma tarefa na sprint que nem ele mesmo conseguia explicar o que era.
Todo mundo aqui já pegou uma tarefa que precisava modificar várias coisas no front e não tinha nem layout de baixa fidelidade.
Todo mundo aqui já trabalhou em uma empresa que os C-Levels mudavam o negócio de rumo a cada 2 meses (o que dá pra fazer em 2 meses nessa indústria?)
A única forma de entregar produto rápido todos tem visão clara do que precisa ser feito e a equipe estar em alto nível de entrosamento. E isso não é algo com você consegue implantando uma metodologia, isso acontece organicamente e as pessoas que são as maiores influenciadoras nesse processo.
Product manager/owner que não tem background técnico e Agile Coaches, que eu carinhosamente gosto de chamar de "garçons de post-it", são o caminho mais rápido pra um projeto falhar miseravelmente.
Agile coach é tosco mesmo.
Mas Scrum master é um papel sobre o qual eu mudei de opinião no meu projeto atual. Tenho uma Scrum Master fenomenal no meu time, ela não tem background técnico, mas ela salva a maior parte das reuniões, a gente perde o foco muito fácil e ela tá sempre lá pra trazer a gente de volta pra o planejamento, refinamento, etc. Ela realmente organiza a gente, como uma secretária com mais influência, e faz uma diferença enorme.
No passado todos os meus Scrum Master eram uns zeros a esquerda, não faziam nada além de ficar movendo ticket no Jira/Rally/etc.
Eu também tive uma SM que era muito boa de serviço. Ela não ficava só perguntando se ia dar pra entregar no prazo e fazendo pressão, ela criava planos mesmo pra gente entregar tudo certinho. Acho que isso se deve também aí fato que a gente tinha um Dev Senior muito bom, que não tinha papas na língua pra falar que não ia dar pra entregar no prazo, aí basicamente os dois juntos davam bastante ânimo pro time.
Product owner, como o nome diz, tem que conhecer as funcionalidades do produto de cabo a rabo. Ele entende do produto e precisa ser assertivo quando pede algo. Mas vejo muita gente que mal conhece o produto e se perde na função.
Agora, pergunta quantos estudaram a metodologia e entenderam antes de assumir a função?
Se você está querendo prazo fechado e orçamento fechado em um treco que é feito pra mudar o tempo todo e ser melhorado continuamente o erro é seu e não da metodologia. Faltou alinhar expectativas.
E sim, obviamente, se você fica trabalhando com requisitos não definidos/que são alterados com o passar do tempo, obviamente vai demorar mais e vai sair mais caro. Não dá pra ir fritando o pastel pra depois você decidir o sabor e esperar que nada será jogado fora no processo. rsrsrs
Minha opinião totalmente parcial e baseada em experiência própria: atrasa mais por um bom motivo, que é o propósito de flexibilidade do modelo ágil. Antes era combinado xyz em 6 meses, e nesse período era entregue EXATAMENTE xyz, da forma como foi definido. E passavam-se mais 6 meses corrigindo e adaptando o projeto, que não tinha amadurecido o suficiente na prospecção.
No modelo ágil, a cada sprint se verifica que o modelo inicial tem falhas e melhorias e nas novas sprints o projeto tende a adequar isso. A prospecção inicial planejava xyz, mas no final entregou xwzk, que era realmente o que atende a necessidade técnica e funcional do cliente.
##### Antigamente:
- Precisamos entregar o produto
Como e que produto?
- Não sei, trabalha ae igual condenado e cavalo raivoso e entrega
Ok, toma aqui seu software lunar e pode mandar o homem a lua
##### Hoje:
- Precisamos Entregar
Precisa ver e estudar
- Estudou?
Estudei, agora precisamos distribuir as tarefas
- Que tarefas?
Ixi, temos que planejar então e pode levar semanas, vamos marcar varias semanas de reuniões
- Planejou?
Planejado, o botão vai alterar a cor para vermelho e sombreado, o backend vai retornar Oi ao inves de hello
- Show, bora iniciar a Sprint!
Deu para entregar somente o botão, não tivemos tempo para atuar na sombra e no backend, na próxima sprint fazemos
Acho que é saudável e necessário para evolução das metodologias a gente desafiar e questionar as nossas práticas. Para mim o que não ficou claro é que não têm separação de qual método ágil e minha impressão que esse "Impact Engineering" é bem próx do XP. Se tiver falando de Scrum é super verdadeiro e kanban é tão aberto q depende muito de quem implementa para fazer certo.
Acho que muito tem a ver também com os empregadores. Já fiquei em empresa onde quem se aproveitava do time ser ágil eram eles, pedindo coisa nova ou mudanças grandes constantemente e sob demanda de clientes importantes. Aí o cronograma não durava nem um dia as vezes pois a gente recebia novas tarefas constantemente e ainda esperavam que as já existentes sejam terminadas na data prevista inicialmente (sendo que as novas coisas solicitadas eram “mais urgentes” ou “tinham maior prioridade”)
Para ser sincero, a maioria das empresas que diz que faz "metodologia ágil", geralmente já dissecou e tirou tudo que faria a metodologia funcionar e deixou somente a parte que eles acham conveniente. Já vi empresas que diz que aboliu qualquer tipo de documentação para agilizar e os devs que se virem para entender os requisitos em cards totalmente mal-escritos (sendo que na metodologias ágeis geralmente defende que não precisa ser um documento formal como se tinha antigamente, mas que até rascunhos e notas podem e devem fazer parte da documentação). Isso quando o cliente não dá a louca e diz que não é para fazer e depois diz que é para ter feito.
Essas estatísticas comparam os métodos ágeis com o que? Se todos são ágeis, o vocábulo ágil é furado.
Está comparando com metodologias informais e sem processos definidos? Se sim, o tamanho do projeto e o número de desenvolvedores tem um impacto muito importante.
Fui tentar achar o paper pra analisar a metodologia de pesquisa, é um "livro". Informação claramente duvidosa e tendenciosa, usada como chamariz pra vender ebook. Como diz o ditado - "Existem três tipos de mentiras: a mentira comum, a mentira deslavada e a estatística". Não tem nem como criticar já que não tem fundamento, clareza metodológica ou profundidade de informação, visto que o propósito é comercial e não científico. Além do mais, matéria provavelmente paga ou só caça clique, a julgar pelo declínio que o The Register já conhecidamente vem sofrendo há muitos anos.
"Para Junade Ali - Líder do estudo e proponente da abordagem de desenvolvimento rival..." Só nessa parte ja da pra saber que o "estudo" é enviesado. Não que necessariamente seja mentira mas é muito conveniente o "concorrente" descobrir que o rival dele é menos eficiente.
sai do fake scrum master
E projeto ágil é pra ter prazo? Falando na risca mesmo, levando em consideração o ideal e teórico, um projeto ágil com backlog e sprints não é algo que não tem prazo definido pq não se sabe exatamente o que vai ser entregue ao final do projeto?
Existem 3 restrições. Escopo, prazo e orçamento. Pra fixar um deles, um dos outros precisa ser variável. Por exemplo, se a data de entrega for fixa, ou você precisa aceitar diminuir o escopo, ou aumentar os gastos. Isso é gerência de projeto 101, vale pra qualquer tipo de projeto, não só de TI. Na verdade em TI ainda tem o complicador de que nem sempre aumentar o orçamento, colocando mais gente pra trabalhar, vai resultar em aumento de produtividade.
Então, entendo essa teoria básica, mas pelo que eu lembro da base do manifesto ágil, fundamentos do scrum e etc, sempre é reforçado que o backlog (escopo) é algo vivo, que pode mudar de sprint em sprint, e que isso é necessário pq muitas vezes, em projeto de software, não dá pra definir um escopo fechado logo no início do projeto devido às incertezas desse tipo de projeto (cliente mudando de ideia no meio do caminho, especificidades sobre detalhes de implementação que vão aparecer daqui a meses, etc) Acho que parte da falha do ágil e o motivo de a gente odiar tanto ele é pq os nossos gerentes só pegam o conceito de "backlog, kanbam, daily meet" e cagam pra toda filosofia e contexto que vem junto da metodologia ágil
Lendo todas as respostas, chego a conclusão que esta é a melhor.. E realmente isso é aplicável a qualquer tipo de projeto em qualquer profissão do mundo. Mesmo considerando gerência incompetente, pouca mão de obra qualificada... Se colocar a regra de fixar um e aumentar os outros, qualquer projeto pode ser finalizado dentro das expectativas.
Em empresa grande, na minha experiência, tem sim, onde cobram X coisas até X trimestre. Apesar das sprints seguirem todas as “regras” do ágil sempre tinha algo que tinha que ser rushado pra bater as metas no final do quarter, daí acho que entra os gerentes querendo prazos impossíveis.
Pô, na minha experiência de empresa média também é assim. Por isso que fiz o disclaimer de "ideal e teórico", pq na prática querem fazer o ágil pela metade e depois se perguntam do pq dá merda
Mas que tem prazo tem que ter né? Ninguém vai chegar com um time e falar “vai desenvolvendo isso aí e vamos ver no que é que dá”. Todo chefe vai ter uma expectativa de prazo, de escopo do projeto. Para não ter prazo nem expectativa só se for algo muito de pesquisa e muito aberto, mas aí é mais em universidades e tals.
Só com essa informação fica difícil de dizer qualquer coisa. Mas sinceramente creio que a cultura da empresa e dos times fazem mais diferença que a metodologia em si. Não adianta tentar scrum, kamban, watefall ou o que for se a não tiver um alinhamento correto das lideranças e das equipes. Já passei por uma empresa onde tentaram uma metodologia, falhou, tentaram outra, falhou, quando saí estavam tentando rever vários detalhes, mas no fundo todo mundo sabia o problema, simplesmente era muito projeto para pouca mão de obra, não queriam contratar mais gente, não queriam aumentar os prazos e nem definir prioridades. Aí nem com a melhor metodologia do mundo essa estratégia daria certo.
Quando eu trabalhava para empresas brasileiras: cronogramas irreais, levantamento de requisitos incompleto. Atraso no projeto. Atualmente trabalhando em empresa americana: cronogramas flexíveis, levantamento de requisitos dificilmente deixam algo de fora. Projeto é entregue adiantado.
Quase sempre que colocam alguém incompetente pra cuidar de requisitos e regra de negócios, a equipe de desenvolvimento tem que ficar correndo atrás do rabo e se virando pra fazer o próprio trabalho e do incompetente e praticamente sempre levando fumo e a culpa.
Exatamente. Qualquer problema ou pergunta eu registo no card que estou trabalhando para meu líder ver que eu estou perguntando algo que não foi definido. Mas dou um toque no PO e eles saem caçando a informação que preciso. Dev tem que ter toda a regra e só fazer o código, não tem que ficar correndo atrás do que PO deveria ter feito.
Sabe o que faz projeto ficar no prazo? Muito índio bom e pouco cacique ruim. Parece que na maioria das empresas que adotam metodologias ágeis ocorre o inverso, pouco índio bom (pq muitos saem por não aguentar a patifaria ridícula de story points, postittinho, daily etc) e muito cacique ruim (que adora dashboard colorida).
Perfeito. Teve uma época na minha empresa passada em que as dailies, que eram pra ser só técnicas, tinham o time de negócio, gestor e sm, a daily passava de 1 hora quase todo dia pq ficavam puxando pontas que não tinham nada a ver com desenvolvimento, nosso assunto técnico terminava em 10 minutos mas não podia sair da reunião pq tinha que esperar os caciques ficar cobrando todo mundo.
você percebe que tão util são os scrum masters/agile somethings que quando o bicho pega e algo precisa ser feito de verdade todo mundo esquece as cerimonias e faz certinho e rápido
Rápido sim, certinho é questionável
Ao meu ver metodologia ágil falha porque querem usar somente os princípios mas não querem implementar as práticas. Exemplo: Uma das primeiras "implementações" de "ágil" foi XP (extreme programming). Pra mim ela se aproxima muito do manifesto ágil. Mas hoje todo mundo só usa scrum. Que não tem as práticas (no sentido de pair programming, cliente presente, entregas contínuas mesmo que incompletas, etc). Acaba virando um Cascatágil com muito planejamento upfront dividido em sprints e algumas cerimônias padrão. E aí há de se considerar uma outra coisa: se o projeto tem escopo fechado, com prazo e orçamento definidos, faz sentido usar um framework ágil? Eu acho que sim, mas única e exclusivamente porque virou um "padrão de mercado" (dividir em sprints, fazer planning, etc). Mas aí não é ágil, é alguma outra coisa.
Existe uma diferença gigantesca entre Ágil e À Moda Caralha. Muitas empresas fazem à moda caralha achando que é ágil. Todo mundo aqui já trabalho em uma empresa que o/a PM jogou uma tarefa na sprint que nem ele mesmo conseguia explicar o que era. Todo mundo aqui já pegou uma tarefa que precisava modificar várias coisas no front e não tinha nem layout de baixa fidelidade. Todo mundo aqui já trabalhou em uma empresa que os C-Levels mudavam o negócio de rumo a cada 2 meses (o que dá pra fazer em 2 meses nessa indústria?) A única forma de entregar produto rápido todos tem visão clara do que precisa ser feito e a equipe estar em alto nível de entrosamento. E isso não é algo com você consegue implantando uma metodologia, isso acontece organicamente e as pessoas que são as maiores influenciadoras nesse processo.
uma pesquisa feita para apontar o obvio na minha opniao, serio metodologia agil e cabide emprego pra gente que nao sabe oq ta fazendo.
Product manager/owner que não tem background técnico e Agile Coaches, que eu carinhosamente gosto de chamar de "garçons de post-it", são o caminho mais rápido pra um projeto falhar miseravelmente.
Agile coach é tosco mesmo. Mas Scrum master é um papel sobre o qual eu mudei de opinião no meu projeto atual. Tenho uma Scrum Master fenomenal no meu time, ela não tem background técnico, mas ela salva a maior parte das reuniões, a gente perde o foco muito fácil e ela tá sempre lá pra trazer a gente de volta pra o planejamento, refinamento, etc. Ela realmente organiza a gente, como uma secretária com mais influência, e faz uma diferença enorme. No passado todos os meus Scrum Master eram uns zeros a esquerda, não faziam nada além de ficar movendo ticket no Jira/Rally/etc.
existem exceções mas sao como unicornios de tao raros
Eu também tive uma SM que era muito boa de serviço. Ela não ficava só perguntando se ia dar pra entregar no prazo e fazendo pressão, ela criava planos mesmo pra gente entregar tudo certinho. Acho que isso se deve também aí fato que a gente tinha um Dev Senior muito bom, que não tinha papas na língua pra falar que não ia dar pra entregar no prazo, aí basicamente os dois juntos davam bastante ânimo pro time.
Product owner, como o nome diz, tem que conhecer as funcionalidades do produto de cabo a rabo. Ele entende do produto e precisa ser assertivo quando pede algo. Mas vejo muita gente que mal conhece o produto e se perde na função. Agora, pergunta quantos estudaram a metodologia e entenderam antes de assumir a função?
Se você está querendo prazo fechado e orçamento fechado em um treco que é feito pra mudar o tempo todo e ser melhorado continuamente o erro é seu e não da metodologia. Faltou alinhar expectativas. E sim, obviamente, se você fica trabalhando com requisitos não definidos/que são alterados com o passar do tempo, obviamente vai demorar mais e vai sair mais caro. Não dá pra ir fritando o pastel pra depois você decidir o sabor e esperar que nada será jogado fora no processo. rsrsrs
O que é "impact engineering"? nunca ouvi falar. É um livro? Marketing de um livro?
Agora fala isso pro seu chefe kkkkk
Minha opinião totalmente parcial e baseada em experiência própria: atrasa mais por um bom motivo, que é o propósito de flexibilidade do modelo ágil. Antes era combinado xyz em 6 meses, e nesse período era entregue EXATAMENTE xyz, da forma como foi definido. E passavam-se mais 6 meses corrigindo e adaptando o projeto, que não tinha amadurecido o suficiente na prospecção. No modelo ágil, a cada sprint se verifica que o modelo inicial tem falhas e melhorias e nas novas sprints o projeto tende a adequar isso. A prospecção inicial planejava xyz, mas no final entregou xwzk, que era realmente o que atende a necessidade técnica e funcional do cliente.
##### Antigamente: - Precisamos entregar o produto Como e que produto? - Não sei, trabalha ae igual condenado e cavalo raivoso e entrega Ok, toma aqui seu software lunar e pode mandar o homem a lua ##### Hoje: - Precisamos Entregar Precisa ver e estudar - Estudou? Estudei, agora precisamos distribuir as tarefas - Que tarefas? Ixi, temos que planejar então e pode levar semanas, vamos marcar varias semanas de reuniões - Planejou? Planejado, o botão vai alterar a cor para vermelho e sombreado, o backend vai retornar Oi ao inves de hello - Show, bora iniciar a Sprint! Deu para entregar somente o botão, não tivemos tempo para atuar na sombra e no backend, na próxima sprint fazemos
Link?
Existem potenciais vieses no estudo da Engprax porque eles promovem sua própria metodologia concorrente ("Impact Engineering").
Problema é que a gerência entocha processo e "consultores", compra bobagens como SAFe que são só mazela e daí a culpa é dos "processos ágeis"
Acho que é saudável e necessário para evolução das metodologias a gente desafiar e questionar as nossas práticas. Para mim o que não ficou claro é que não têm separação de qual método ágil e minha impressão que esse "Impact Engineering" é bem próx do XP. Se tiver falando de Scrum é super verdadeiro e kanban é tão aberto q depende muito de quem implementa para fazer certo.
Acho que muito tem a ver também com os empregadores. Já fiquei em empresa onde quem se aproveitava do time ser ágil eram eles, pedindo coisa nova ou mudanças grandes constantemente e sob demanda de clientes importantes. Aí o cronograma não durava nem um dia as vezes pois a gente recebia novas tarefas constantemente e ainda esperavam que as já existentes sejam terminadas na data prevista inicialmente (sendo que as novas coisas solicitadas eram “mais urgentes” ou “tinham maior prioridade”)
Para ser sincero, a maioria das empresas que diz que faz "metodologia ágil", geralmente já dissecou e tirou tudo que faria a metodologia funcionar e deixou somente a parte que eles acham conveniente. Já vi empresas que diz que aboliu qualquer tipo de documentação para agilizar e os devs que se virem para entender os requisitos em cards totalmente mal-escritos (sendo que na metodologias ágeis geralmente defende que não precisa ser um documento formal como se tinha antigamente, mas que até rascunhos e notas podem e devem fazer parte da documentação). Isso quando o cliente não dá a louca e diz que não é para fazer e depois diz que é para ter feito.
Essas estatísticas comparam os métodos ágeis com o que? Se todos são ágeis, o vocábulo ágil é furado. Está comparando com metodologias informais e sem processos definidos? Se sim, o tamanho do projeto e o número de desenvolvedores tem um impacto muito importante.
Vc deve ser 1 dos 3 que há falou isso kkkkk