Não é verdade que 65% dos projetos que utilizam agilidade falham. Ainda não encontramos nossa Bala de Prata.

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Compartilhe:

Há cerca de uma semana um estudo com um título bombástico tomou conta da web: “268% dos projetos que passaram a utilizar Métodos Ágeis pioraram e 56% passaram a falhar”, dizia o título. E ao ler o conteúdo, pareceu que havíamos encontrado a solução que resolveria todos os problemas economizando mais de U$ 155 bilhões de dólares por ano. A premissa de Frederick Brooks estaria errada? Existe uma Bala de Prata.

Recebi através de mensagens em alguns grupos de WhatsApp. Todavia não quis me intrometer porque sou um tanto ranzinza e detesto entrar em discussões online. Deixei rolar, mas algo me chamou a atenção, foi o número 268. Trabalho com projetos desde 1998, com Métodos Ágeis (Agilidade) desde 2008 e nem nos meus piores dias esse número me pareceu crível. Das três hipóteses, apenas uma poderia ser verdadeira: a) eu sou um gênio e só trabalhei com pessoas geniais toda minha vida profissional; b) os 600 engenheiros de software que responderam à pesquisa são as pessoas mais azaradas do mundo; ou c) esse estudo tem algum erro.

A pesquisa sobre projetos que falham

A pesquisa foi feita por um pesquisador, Junade Ali, e pela empresa J.L. Partners entre os dias 3 e 7 de maio de 2024. Responderam à pesquisa exatamente 600 engenheiros de software, sendo 250 do Reino Unido e 350 dos EUA. Segundo as respostas, 481 respondentes disseram que seu último projeto foi um sucesso e 119 disseram que falharam. 

Os números dos projetos que falharam são contundentes:

Agile Requirements Engineering (Engenharia de Requisitos Ágeis)

Projetos que utilizam Agile Requirements Engineering ou Engenharia de Requisitos Ágeis o que seria apenas uma parte dos Métodos Ágeis teve uma taxa de falha de 65% e um aumento de 268% de quando utilizava-se outra metodologia. O estudo fornece mais duas variáveis interessantes, a Estatística-T e o Valor-P. 

A Estatística-T, em uma forma simples seria o seguinte: Imagine que você tem uma nova receita de bolo e quer saber se ela realmente faz um bolo mais gostoso do que a receita tradicional que você usa. Você decide testar isso de forma científica. Você faz 10 bolos usando a receita nova e pede para 10 amigos darem uma nota de 0 a 10 para cada bolo. Depois, você faz 10 bolos usando a receita antiga e pede para os mesmos amigos darem notas novamente. Agora, você tem duas médias: uma média de notas para os bolos da receita nova e outra média para os bolos da receita antiga. Você quer saber se a diferença entre essas médias é grande o suficiente para concluir que a nova receita é realmente melhor, ou se a diferença pode ter ocorrido apenas por acaso.

No caso da Estatística-T, previsivelmente deu 4,94 o que é um valor alto o que é esperado já que há um aumento de 268%. Indica que a Engenharia de Requisitos Ágeis é 4,94 vezes pior se comparada ao método anterior, seja lá qual for.

O Valor-P, neste caso, é complementar. Se você oferecer as duas receitas de bolo para outros 10 amigos e repetir o processo várias vezes, ele nos ajuda a entender se a diferença observada é significativa ou poderia ser explicada pelo acaso. Valores-P abaixo de 0,05 indica que é improvável que as notas obtidas pelas receitas de bolos sejam ao acaso. Maiores do que 0,05 indicam que elas podem ocorrer ao acaso e não há evidências suficientes para determinar se uma receita é melhor do que a outra.

O uso mais famoso da Estatística-T e Valor-P são para testes de Hipótese Nula. Esse é um valor previamente definido que se não for atingido indica que a hipótese nula é a correta e o produto, método, serviço utilizado não produz mudanças significativas. Neste estudo é utilizado como números de comparação.

No caso, o Valor-P da pesquisa é 3,83E-5, ou 0,0000383. Esse número diz que se repetirmos o experimento, temos uma chance de 0,00383% de observar uma diferença tão extrema (ou maior) entre as médias devido ao acaso. Logo é estatisticamente significativo.

Lean Software Development (Desenvolvimento de Software Enxuto)

Há uma observação no estudo que afirma que os desenvolvedores respondestes trabalharam apenas em um projeto, não há paralelismo. Neste caso a taxa de falha é de 21%, um aumento de 7% se comparado ao método anterior. A Estatística-T é de 0,59 o que seria baixo e o Valor-P de 0,55. Isso significa que é estatisticamente inconclusivo, pois os dados não fornecem evidências suficientes para concluir se o método impacta ou não na taxa de falha.

Impact Engineering (Engenharia de Impacto)

Aqui também há uma observação que afirma: “Utilizando de todas as práticas de engenharia estudadas (provavelmente no Método Engenharia de Impacto) que aumentam as taxas de sucesso.”. Neste caso, a taxa de falha foi de 10%, na verdade representa uma redução de 56% de falhas (melhora em 56%). A Estatística-T é negativa, -4.15 o que é muito baixo. Utilizando a mesma lógica é como se esse método fosse 4,15 vezes melhor do que utilizar o método anterior. O Valor-P é 4,11E-5 ou 0,0000411 o que indica que não é um resultado ao acaso.

Analisando os resultados da pesquisa.

Existem outras informações na pesquisa que você pode achar no site da Engprax. Se olharmos para os resultados obtidos, diríamos que a Impact Engineering é realmente a solução dos problemas. Estamos falando de uma piora brutal utilizando métodos ágeis, de algo inconclusivo utilizando o Lean e uma solução que representa uma melhora de 56%. 

Os entrevistados

Entretanto, temos que olhar para as outras variáveis do texto. Primeiro a população utilizada na pesquisa. 600 desenvolvedores de software. Não há dados que poderíamos considerar importantes para a análise: Por exemplo, qual a relação deles com a Engprax, tamanho das empresas, tipos de projetos, eles acreditam que seus projetos foram realmente um fracasso ou um sucesso, sexo, anos de experiência profissional, setor em que a empresa atua etc. A única informação que temos é que são dos EUA e do Reino Unido e deduzo que uma boa parte deles conhece o Impact Engineering, pois confesso que foi a primeira vez que vi esse termo aparecer.

O critério

O critério de sucesso que foi utilizado é: entregar todo o escopo acordado dentro do prazo estabelecido. Foi aqui que me prendi. A falta de informação sobre os entrevistados já era ruim, o fato deles saberem de um método desconhecido também levanta suspeitas. Entretanto, afirmar que o sucesso de projetos é entregar 100% do escopo no prazo, aí eu percebi o problema com a premissa da pesquisa. Ela cobrou Métodos Ágeis e Lean por algo que ambos não entregam. Fazendo uma analogia, seria como eu dizer que o Peixe perde da Galinha porque não consegue voar 2 metros

Olhando para a minha vida profissional

Sinceramente, se tivessem me perguntado utilizando esse critério se os projetos que entrego são sucesso ou fracasso, eu seria a resposta 120 de fracasso. Por dois motivos, o primeiro é que eu digo muitos “nãos”. Muitas das vezes, tenho clientes mais difíceis e não aceitam o meu “não” e tem o poder político e hierárquico para forçar o “sim”. Eu não brigo e nem discuto. Coloco no backlog e lá na frente provo para ele que não precisa daquilo. 

Afinal, pedir é barato, quase de graça. Entregar o que o cliente precisa é uma arte que toda pessoa de produto leva um tempo para desenvolver. Logo, nunca, em mais de 25 anos de trabalho, jamais entreguei 100% do escopo solicitado e isso é uma coisa boa. Entregar tudo é custoso para você, seu cliente e seu time. No final será empregado muito esforço para pouco ou nenhum resultado tanto para o seu cliente quanto para a empresa.

Outro motivo é que se você trabalha com software, como é o caso dos entrevistados, você sabe que não cria projetos, você cria produtos e serviços. O meu produto mais antigo está no ar desde 2007. Esse “filho” mais velho tem 17 anos, mais velho do que a minha filha de verdade. Obviamente não concluímos um projeto em 2007 e largamos ele lá em produção. Ele vem sendo atualizado tanto na tecnologia quanto nas funcionalidades desde então.

Se for bem, bem sincero, o produto mais antigo que participei e ainda está no ar é do ano 2000. Não estou mais na empresa, mas ele ainda está lá firme e forte. As tecnologias que utilizei sequer rodam nos computadores modernos. Ele vem sendo mantido há 24 anos por outros desenvolvedores, resolvendo o problema para o qual ele foi construído.

Medindo o sucesso de projetos através das Métricas nas 4 Áreas de Domínio da Agilidade

O critério todo o escopo em todo o tempo é um critério pobre. Sempre analiso sucesso ou fracasso com métricas nos 4 Domínios. Não digo que tenho sucesso em tudo, pelo menos não quando eu e meus times gostaríamos, mas desde 2008, quando adotamos Métodos Ágeis, nunca mais recebemos reclamação de que não entregamos soluções que resolveram o problema do cliente no prazo que tínhamos. Mesmo quando o prazo era menor do que 2 semanas. Resolver o problema do cliente, mais do que entregar 100% do escopo. Vejamos a imagem abaixo:

Métricas nas 4 Áreas de Domínio da Agilidade para criação de Projetos, Produtos e : Negócio com as métricas de eficácia: Receita, Net Promoter Score,
Churn, RoI, Retenção e Aquisição. Cultural com as métricas de Ecossistema: Saúde do Time, Burnout, Satisfação com Trabalho, Eficácia do Feedback, Níveis de Delegação e Rotatividade
Organizacional com as métricas de eficiência: Customer Lead time, Taxa de Entrega, Tempo de Bloqueio, Vazão (Throughput), Work in Progress (WIP) e Custo e Prazo
Técnica com as métricas de Excelência: Reclamações, Devoluções, % Cobertura de Testes, % Automação do trabalho e% Padronização do trabalho
Métricas nas 4 Áreas de Domínio da Agilidade

Se quiser saber mais sobre as 4 Áreas de Domínio da Agilidade, clique aqui. Métricas de Eficácia estão: aqui, aqui, aqui e aqui. Métricas de Eficiência você pode encontrar aqui, aqui, aqui e aqui. Já as de Ecossistemas estão disponíveis também no nosso blog seguindo este link e este aqui também. Por fim, temos métricas de Excelência aqui.

Meu intuito aqui não é explicar os pormenores das métricas, mas como vocês podem ver: prazo é apenas um ponto dentro de uma das áreas. O estudo ignora todo o resto. Inclusive da própria área. 

Uma Onça caminhando sobre um rio

Nós da Nower / K21 afirmamos que a criação de projetos, produtos e serviços é como um animal de quatro patas, cada uma representando uma área da agilidade. Se você ignorar uma delas é o equivalente a quebrar uma das patas do animal. Ele anda, porém anda mancando. Por exemplo:

Se ignorarmos a área de Negócio, não temos eficácia. Então entregamos um produto no prazo, com qualidade, porém ninguém quer e ninguém usa.

Se ignorarmos os aspectos culturais, não criamos um ecossistema saudável. As pessoas criam produtos que os clientes querem de forma eficiente e com qualidade, porém se apagar a luz e jogar facas na sala, vai morrer gente. Com o tempo a rotatividade ficará alta e você não terá nem eficiência, nem eficácia e nem qualidade.

Se ignorarmos a eficiência organizacional podemos ter até uma solução de sucesso, mas o tempo que leva para entregarmos e adaptarmos às mudanças do ambiente será horrível. 

Se ignorarmos a excelência técnica, como diz o Rodrigo de Toledo, é igual a cuspir para cima e ficar em baixo esperando o cuspe voltar.

O estudo quebrou totalmente 3 patas e ainda machucou a 4ª utilizando um critério apenas.

Conclusão

Se você olhar para os seus projetos e sabe que 65% deles não falharam, não fique assustada ou assustado. Ainda não encontramos a nossa Bala de Prata. Essa pesquisa é o que na academia chamamos de Pesquisa de Autopromoção. Ela “demonstra” o “sucesso” do produto que a empresa vende em detrimento de outras, especialmente as líderes de mercado. São comuns em remédios de emagrecimento, perda de cabelo, aprendizado e outros. 

Na verdade, é um grande clickbait (isca de cliques) que funcionou. Causou um burburinho, várias pessoas replicaram, todavia algumas já fizeram a observação de que é uma Autopromoção. 

Não posso afirmar se o tal  Impact Engineering é bom ou ruim, pois não li o livro, mas confesso que a desonestidade científica já fez com que perdesse alguns pontos comigo. Soou como um falso profeta que anuncia o apocalipse iminente, mas ele já tem a solução para o problema.

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Sobre o autor(a)

Trainer na K21

Avelino Ferreira é formado e mestre em Ciência da Computação. Teve uma longa trajetória na TI, começando como programador e chegando a gestor de diversos times de criação de produtos digitais. Conheceu e começou a adotar as melhores prática de de Métodos Ágeis em 2008. Desde então, se dedica a auxiliar outras empresas na construção da cultura ágil. Atualmente, é Consultor e Trainer na K21

Artigos relacionados

Nas discussões e workshops sobre OKRs que fazemos nas empresas, um conceito sempre aparece: Estão faltando métricas de guard rail para equilibrar esses OKRs! As Métricas de saúde (ou Guard Rails) ajudam a liderança e as equipes a manterem um…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

O que é gargalo Quando falamos sobre Kanban um dos nossos principais objetivos é identificar onde está o gargalo do nosso fluxo. O gargalo é a etapa em que os itens permanecem por mais tempo. É fundamental resolver os gargalos…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Seja em treinamentos, consultoria ou até mesmo com meus times de desenvolvimento. Uma coisa fácil de perceber é o desconforto causado quando comento sobre a necessidade de limitação de WIP. É algo que me causa estranheza. Por que as pessoas…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

No artigo anterior, comentamos sobre o que era o Kanban, qual problema ele resolve e os princípios que norteiam esse método de gestão de trabalho. Este artigo é um complemento ao primeiro e nele quero tratar as práticas que o…