Projetos que utilizam agilidade falham? 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:
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.
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.
Se quiser saber mais sobre essa mesma polêmica, dê uma olhada no artigo do Marcos Garrido: Projetos com Agilidade teriam 268% mais chance de falhar. Será?
