Agile é o rigor mortis como religião de estado do software

Não é incomum no mundo da engenharia de software ouvir proclamações sobre a morte do Agile de pessoas com interesse na metodologia, alegando que, a menos que demonstremos mais fé, ele será perdido e, nos casos em que falha, ele simplesmente não foi implementado corretamente - uma reminiscência de outras alegações que seguem a falácia do "escocês não é verdadeiro", como "o comunismo real nunca foi tentado".

Apesar de sua presença em catástrofes de software que variam de erros judiciais a desastres de software de aviação, a realidade é que o Agile manteve uma posição como uma espécie de religião profissional da engenharia de software.

Essa situação mudou profundamente nos últimos meses. Desde que trabalhei em uma pesquisa há 6 meses mostrando que projetos de software Agile tinham uma taxa de falha 268% maior , uma infinidade de pesquisas surgiram corroborando esse trabalho.

Assim como o comunismo ou a cura pela fé, as fantasias de grandeza de que soluções universalmente boas, mas irrealistas, podem resolver todos os nossos problemas sempre atrairão alguns, apesar das evidências - mas o que mudou fundamentalmente agora é que existe um consentimento informado sobre seguir o Agile ou fazer algo diferente.

(Sem dúvida, as notícias internacionais associadas à atualização de software malfeita do CrowdStrike certamente ajudaram a enfatizar os pontos que eu estava tentando abordar.)

Apesar do quão repugnante alguns na comunidade Agile tentaram me silenciar para não falar sobre Agile, é importante ser magnânimo na vitória, então não tentarei reacender os argumentos aqui. Em vez disso, sinto que vale a pena discutir os desenvolvimentos recentes e o caminho a seguir, 6 meses depois.

Pesquisa DORA do Google ativa o Agile

A JL Partners, que contratei para conduzir a pesquisa de taxa de falha Agile, teve alguns meses fenomenais. Ao contrário de muitos outros que conduzem pesquisas com responsabilidade limitada, eles testam regularmente seus modelos prevendo eleições. Quando se tratou das eleições do Reino Unido, eles se viram produzindo entre as previsões mais precisas . As coisas são ainda mais notáveis quando se trata da eleição dos EUA , como relata o Politico :

… A JL Partners pode muito bem acabar sendo uma das mais precisas em suas previsões finais pré-eleitorais. O modelo final da empresa foi apenas um dos dois a prever uma vitória de Trump e também projetou sua vitória no Colégio Eleitoral por 287-251 — a maior margem projetada para vitória de Trump de qualquer pesquisador. Foi também um dos poucos pesquisadores a prever que Trump venceria o voto popular.

Além disso, uma pesquisa da RAND Corporation conduzida inicialmente para o Departamento de Defesa dos EUA descobriu que o desenvolvimento de IA e o ágil não combinam bem . Além disso, a Synodus (um provedor global de tecnologia que fornece (empresas da Fortune 500 como BOC Aviation, KPMG e Unilever) está relatando que, ao se afastar do Agile , eles estão descobrindo que estão entregando projetos 2 a 3 vezes mais rápido e relatando que uma companhia aérea líder economizou 63% de seus custos de desenvolvimento.

Isso ocorre apesar do fato de que velocidade e custo são tradicionalmente métricas associadas ao Agile e ao LEAN, enquanto a abordagem da Engenharia de Impacto se concentra no Impacto como métrica primária.

Finalmente, como Colm Campbell escreveu no artigo “ P-Hacking com Dinossauros ”, as alegações apresentadas pela “Máfia Ágil” em resposta ao estudo de taxa de falhas do Agile foram completamente refutadas, deixando apenas ataques pessoais patéticos.

No entanto, talvez uma das áreas mais surpreendentes de suporte à pesquisa venha da equipe DORA do Google. A própria DORA encontra suas raízes no movimento DevOps, que por si só é uma criatura do Agile. Seu Relatório Anual do Estado do DevOps para 2024 não recebeu nenhuma cobertura particularmente ampla este ano, dado o tempo de antena que foi para a pesquisa Agile, mas é interessante ver que eles estão dando as costas ao Agile também.

Agora, devo ressaltar que tenho criticado a metodologia da equipe DORA (desde que mudei de ideia sobre Agile, DevOps, etc.), pois as principais métricas que eles usam para medir as coisas são focadas na velocidade de entrega ( que sabemos que não é o que os usuários querem ), mas o fato de eles estarem vendo isso mesmo usando sua abordagem aponta para algo mais profundo acontecendo aqui.

Na página 64 do Relatório do Estado do DevOps 2024, eles afirmam:

'O manifesto Agile defende “software funcional em vez de documentação abrangente”. Continuamos a descobrir, no entanto, que a documentação de qualidade é um componente essencial do software funcional.'

Além disso, na página 82, eles parecem dar as costas ao próprio DevOps:

'Estamos comprometidos com os princípios fundamentais que sempre fizeram parte do movimento DevOps: cultura, colaboração, automação, aprendizado e uso da tecnologia para atingir objetivos de negócios. Nossa comunidade e pesquisa se beneficiam das perspectivas de diversas funções, incluindo pessoas que podem não se associar ao rótulo "DevOps". Você deve esperar ver o termo "DevOps" saindo dos holofotes.'

Ainda tenho problemas com a metodologia de pesquisa deles; os parâmetros usados para medir o sucesso são focados na velocidade e, além disso, eles continuam defendendo a liderança transformacional, apesar da pesquisa psicológica nessa área questionar tais abordagens.

Em um nível humano, parece notavelmente grosseiro focar tanto em tentar transformar organizações e pessoas sem seu consentimento informado, ao mesmo tempo em que falha em reconhecer que muitas vezes não há melhor fonte de aprendizado do que nossos próprios erros (na medida em que temos o consentimento informado para cometê-los), uma crítica fundamental que tenho a trabalhos como The Pheonix Project e The Unicorn Project .

No entanto, é notável ver uma crescente corroboração da Engenharia de Impacto em relação às métricas tradicionais de Agile e DevOps.

Scrum, TDD e Padrões de Design

Quando o The Register me entrevistou alguns meses atrás no artigo “ Estudo patrocinador: abordagens catastróficas sobre Agile enfatizam demais os novos recursos ” , não escondi os três fatores com os quais tive problemas nas abordagens modernas para Agile, DevOps e transformação digital:

1. Abordagens do Agile que depreciam requisitos, apesar de desastres como o escândalo dos Correios e as quedas do Boeing 737 Max 8 .

   
   

2. Implementações de DevOps que priorizam a velocidade de entrega de novos recursos e recuperação de problemas em vez de prevenir problemas em primeiro lugar - apesar de pesquisas mostrarem que o público classifica a obtenção dos recursos mais recentes o mais rápido possível comoa coisa menos importante para eles ao usar sistemas de computador, com segurança de dados, precisão de dados e ausência de bugs sérios sendo os fatores mais importantes.

   
   

3. Tentativas de transformação organizacional de baixo para cima sem obter consentimento informado, negligenciando a importância de permitir que as pessoas aprendam com seus próprios erros que elas têm o consentimento informado para cometer - com tais programas vendidos como sucessos infalíveis terminando esmagadoramente em sofrimento e fracasso estressantes.

   
   

Quando comecei a pesquisar desastres de software e computadores assassinos (conforme relatado na Forbes em abril ), esses foram os três fatores com os quais comecei a ter desafios morais crescentes. Não tive nenhum problema real com diferentes abordagens de desenvolvimento de software ou técnicas de gerenciamento de projetos, pois não vi o mesmo link para os estudos de caso de desastre que estava investigando. Não senti necessidade de expressar minhas opiniões pessoais como engenheiro com relação a esses outros assuntos.

No entanto, é interessante ver que o raio de explosão se ampliou além dessas três áreas iniciais para outras abordagens defendidas pelos coautores do Manifesto Ágil, como Scrum, Desenvolvimento Orientado a Testes (TDD), Programação Orientada a Objetos (POO) e Padrões de Design (por exemplo, veja a postagem de Soumen Sarkar no LinkedIn sobre Padrões de Design ).

Tenho pouco a acrescentar nesta área. No entanto, eu me pergunto se os coautores do Agile não tivessem lutado tanto contra sua morte como religião se a comunidade de engenharia de software teria sido mais gentil com suas outras ideias. A questão agora é discutível, dado que o status religioso do Agile é rigor mortis e tudo parece estar em jogo: POO, padrões de design, TDD, etc.

Rumo à conscientização da aversão à perda

Como passei uma proporção relativamente considerável dos últimos meses sendo notícia de primeira página de várias publicações de tecnologia falando sobre Agile e sendo muito amplamente discutido entre a comunidade em geral, talvez não fosse surpreendente ter alguns encontros bizarros. Na maior parte, porém, eles foram encontros extremamente agradáveis de pessoas vindo até mim em público e se envolvendo aleatoriamente em discussões sobre Agile.

No entanto, houve um encontro que deixou uma forte impressão em mim. Algumas semanas atrás, eu estava indo ao Parlamento do Reino Unido para falar com formuladores de políticas sobre vários escândalos de tecnologia que eu estava investigando. Eu nunca fui muito fã de ter poder, e sempre achei curioso que nos bares privados do Parlamento, tenha que haver placas lembrando os indivíduos de não abusar de seu poder quando intoxicados.

No entanto, ao dar esta palestra, eu não estava apenas bem vestido e mais apresentável do que o normal, mas também estava diante de uma plateia simpática, ladeada por um membro do Parlamento e um amigo que por acaso é um Conselheiro do Rei (um advogado sênior que recebeu essa distinção do monarca por sua advocacia excepcional).

Depois que dei minha palestra e respondi a uma série de perguntas, havia alguém na plateia que era um visitante que começou a falar sobre Agile (a palestra não tinha sido sobre Agile). Em contraste com meu terno de três peças, ele estava vestido com uma camisa manchada de ketchup e (sem entrar em detalhes) não era nem apresentável nem politicamente conectado. Ele começou "Posso lhe dar um feedback?"

Quando ele começou a falar sobre Agile, fiz contato visual com ele, intrigado, e ele olhou para baixo e parou de falar, quase como se percebesse que não estava mais online e realmente encarando alguém com suas palavras. Antes que eu pudesse responder, um amigo CEO interrompeu para abordar o ponto para mim.

Naquele momento, percebi que não gostava de poder de uma forma que ainda não havia percebido.

Infelizmente, para esse indivíduo, parecia que ele já tinha sido vítima daqueles que vendiam soluções de transformação infalíveis, aparentemente levando a dificuldades em sua própria vida. Nessas circunstâncias, por que essas metodologias de transformação ainda são defendidas?

Mais amplamente, por que o Agile não consegue operar no mundo real? Com o comunismo, pelo menos podemos atribuir o fracasso à ganância, então qual é a psicologia do fracasso do Agile? A resposta, aos meus olhos, se resume a um fator psicológico conhecido como aversão à perda . Por demanda popular, recentemente escrevi um artigo pré-impresso sobre o trabalho da Impact Engineering e ele se concentrou no papel que a conscientização da aversão à perda pode desempenhar na mitigação do sucesso do projeto.

O artigo, “Então eu sou o Dr. Frankenstein? Ou você era um monstro o tempo todo?”: Mitigando falhas em projetos de software com metodologias de desenvolvimento conscientes de aversão a perdas , conclui o seguinte:

Estudos de caso mostraram que desastres de software podem se transformar em catástrofes quando os problemas não são abordados e, em vez disso, são encobertos. Fatores psicológicos, sendo um deles a aversão à perda, podem incentivar as organizações a seguir esse caminho, apesar das consequências desastrosas.

No entanto, as metodologias de software historicamente desconsideraram esse fator psicológico, em vez disso, assumindo que os humanos desejarão abordar os problemas na primeira oportunidade. Pesquisas anteriores de metodologias variadas descobriram que a segurança psicológica para levantar e discutir questões é a chave para melhorar a entrega de software. No entanto, é sem dúvida otimista acreditar que uma mudança cultural e psicológica tão significativa pode ser alcançada em todas as organizações. Como descobrimos, mesmo entre o Reino Unido e os EUA, a segurança psicológica continua sendo a maior diferença na prática de engenharia entre os dois países.

Neste artigo, focamos em um caminho diferente a seguir. Em vez de tentar alcançar uma mudança cultural que é, na melhor das hipóteses, desafiadora, focamos em uma abordagem mais pragmática: limitar os gatilhos da aversão à perda desde o início por meio de requisitos robustos e, então, visar a segurança psicológica onde for necessária. Em nossa pesquisa, o único fator que descobrimos que aumentaria a taxa de sucesso de um projeto mais do que a segurança psicológica foi ter requisitos claros desde o início.

Contra nossa hipótese, os resultados de que apenas ter requisitos claros, mesmo quando eles mudam tarde no desenvolvimento ou não estão alinhados com o mundo real, parece ter um papel significativo no sucesso do projeto de software. Isso sugere que ter um portão antes do início de um projeto para discutir e abordar problemas, quando a aversão à perda está no seu nível mais baixo, permite a maior melhoria nas taxas de sucesso.

A música Dr. Frankenstein do RedHook contém o refrão: “Então eu sou o Dr. Frankenstein? Ou você era um monstro o tempo todo?” Para projetos de software catastróficos, este artigo argumenta que os projetos de software se tornam desastres quando os humanos falham em resolver problemas técnicos de menor escala. As metodologias de engenharia de software existentes falham em resolver que os humanos não são máquinas e que fatores psicológicos impedem a capacidade de resolver problemas. Tendo identificado esse anacronismo nas metodologias existentes, este artigo apresenta como podemos agir sobre ele usando requisitos antes do início de um projeto para fornecer a oportunidade de resolver problemas quando a aversão à perda estiver no seu nível mais baixo.