Da perseguição às tentativas de hacking, desde que comecei a pesquisar a alta taxa de fracasso de projetos Agile e iniciativas de transformação, fiquei cara a cara com o fundamentalismo que existe entre os seguidores mais devotos do Agile.
Quando os pacientes vulneráveis de um curandeiro sucumbem a uma doença como resultado de um tratamento falso que não funciona (tendo geralmente “doado” uma quantia considerável de dinheiro), o “curandeiro” muitas vezes alegará que a culpa é do paciente, pois eles não oraram muito suficiente. Este foi um tópico explorado extensamente por Derren Brown no especial de TV Miracles for Sale e teatralmente em seu especial da Netflix, Miracle . Tal falácia é frequentemente descrita como uma versão da falácia “ Nenhum escocês verdadeiro ” ou um “ apelo à pureza ”.
Os fundamentalistas da comunidade Ágil costumam usar afirmações semelhantes quando os projetos Ágeis falham. Por exemplo, no artigo “ Failing at Agile? Você está fazendo errado “, Greg Kihlstrom escreve:
Por exemplo, você poderia ter o Scrum Master mais entusiasmado possível em sua equipe, mas se a equipe de produto tiver alguns pessimistas ou aqueles que simplesmente não seguem ou entendem o que precisa ser feito, você terá desafios. Às vezes é uma questão de educação ou coaching, e às vezes é uma questão de dinâmica e cultura da equipe. Determine qual é a causa e lide com ela de acordo.
No entanto, a base científica para tal crença não existe. Um artigo de novembro de 2021 intitulado ' “Melhores Práticas” sem Evidência – Metodologia Ágil de Software como Exemplo ' conduziu uma meta-análise de inúmeras revisões de estudos científicos Ágeis e descobriu: “O resultado do estudo terciário é que, de fato, a evidência para o A metodologia ágil é, na melhor das hipóteses, escassa.”
Contudo, este está longe de ser o único viés cognitivo adotado por aqueles que assumem uma postura fundamentalista quando o assunto é Agile. Neste artigo, gostaria de focar nos espantalhos que são frequentemente usados para justificar a metodologia Ágil.
Na comunidade Agile do LinkedIn, não é incomum ver postagens como as seguintes - aparentemente uma conversa que faz um praticante Agile parecer perspicaz e defender a metodologia diante de um engenheiro de software que ousa questioná-la. É minha opinião pessoal que essas conversas parecem geralmente fictícias:
O Oxford English Dictionary fornece o seguinte como definição de espantalho:
Em uma discussão, debate, etc.: uma proposição intencionalmente fraca ou deturpada, criada porque é mais fácil de derrotar ou desvia a atenção do argumento real de um oponente, dando a impressão superficial de que a acusação original foi refutada ou derrotada .
No entanto, existem espantalhos muito mais enraizados que parecem ir ao cerne da proposta Ágil.
Um artigo no site SecretGeek levantou a questão: “ 'Agile' é uma religião? (ou apenas um culto) ”. Embora o autor tenha afirmado que os outros elementos dogmáticos do Agile estavam de fato em vigor, desde os rituais até a doutrina, a única área sobre a qual eles estavam em dúvida era se havia uma “mitologia” no Agile.
Acredito que esses espantalhos são fundamentalmente o que forma a mitologia do Agile.
É difícil ver o Agile discutido sem a discussão do Waterfall. Uma suposta metodologia de gerenciamento de projetos com a qual o Agile contrasta. Uma metodologia que requer etapas rigorosamente documentadas e nunca fazendo alterações.
No entanto, isso levanta a questão: onde estão as conferências ou grupos de usuários em cascata, mesmo historicamente?
Talvez as origens da metodologia nos forneçam algumas pistas. Nas notas de palestra de Jon Pearce na San Jose State University, ele afirma: “ O modelo de ciclo de vida em cascata é o espantalho dos modelos de ciclo de vida. Foi descrito pela primeira vez em 1970 por Wynn Royce como um exemplo de um processo falho… ”
O desenvolvedor de software Christian Findlay fez uma afirmação semelhante em uma postagem no X afirmando : “A abordagem em cascata é um espantalho que nunca existiu realmente” .
No entanto, a situação fica mais obscura à medida que nos aprofundamos na história do Agile.
O Sistema Toyota de Produção (TPS) é o berço espiritual da metodologia Ágil. Apesar da esmagadora maioria das iniciativas de transformação falharem, muitos apontarão para a metodologia utilizada pela Toyota.
No entanto, a própria Toyota tem uma história nada ideal quando se trata de engenharia de software. Um relatório do Capitol Weekly afirma que, “Sem admitir responsabilidade, a Toyota desde 2014 resolveu 537 reclamações culpando a aceleração repentina por acidentes que mataram ou feriram gravemente pessoas, de acordo com um documento judicial que a Toyota apresentou” em setembro de 2019.
Esses defeitos de aceleração não intencionais não foram apenas fatais em numerosos casos, mas no caso de Koua Fong Lee, o defeito levou não apenas a um acidente de carro que matou três pessoas e feriu outras quando levava sua esposa grávida e filhos da igreja para casa, mas também levou para ele ser culpado e condenado à prisão. Em processos judiciais, a Toyota tentou contestar uma teoria de por que o veículo se comportou de forma errática com alegações de protocolos de testes robustos, mas pouco antes do julgamento, a Toyota apresentou uma declaração desse engenheiro afirmando que a empresa na verdade não realizou tais testes .
Depois de se recusar a aceitar um acordo judicial que o teria libertado, mas o teria deixado rotulado como criminoso, Lee foi finalmente libertado depois que um novo julgamento foi ordenado, e a promotoria se recusou a levar o caso de volta ao tribunal.
O caso do Bookout V. Toyota trouxe o foco às práticas de engenharia de software da Toyota depois que outro defeito de aceleração não intencional levou a fatalidades. Durante estes procedimentos, que finalmente concluíram que os sistemas de software poderiam causar aceleração não intencional, foram apresentadas evidências, incluindo comunicação interna dentro da Toyota afirmando que “na verdade, tecnologia como a failsafe não faz parte do DNA da divisão de Engenharia da Toyota”:
Após este caso, foi relatado que a Toyota adotou uma abordagem tradicional de engenharia de software para projetos de alta confiabilidade, usando a linguagem SPARK Ada, onde contratos de design rigorosos ajudam a verificar matematicamente a correção do software - uma abordagem adotada em ambientes de alta confiabilidade, como a aviação. e defesa.
Essa abordagem, conhecida como “design por contrato”, foi originalmente inventada pelo engenheiro de software francês Bertrand Meyer, que escreveu o livro “ Agile!: The Good, the Hype and the Ugly ”. Entre as críticas de Meyer ao Agile estão a descontinuação do design inicial e o foco nas histórias de usuários em vez de especificações generalizáveis.
Essas críticas são descritas com mais detalhes no vídeo – “ The Ugly of Agile (with Dr. Bertrand Meyer) ” do Edensoft Labs:
Os vários espantalhos do Agile nos destacam a importância que todos devemos ter em sermos críticos antes de adotarmos soluções que ainda não comprovaram sua eficácia. Não me interpretem mal, não precisamos de meta-análises de revisões sistemáticas de ensaios clínicos randomizados para fazer todos os julgamentos na vida, mas devemos ter cuidado ao descartar evidências de uma base evidencial mais elevada do que aquelas de uma base evidencial mais baixa ( como aqueles que nos são apresentados como verdades dogmáticas por figuras de autoridade).
Como humanos, as histórias de transformação, apesar das probabilidades, tocam nossos corações, e todos nós queremos acreditar que existem super-heróis que podem nos curar. No entanto, o cinismo cego também pode muitas vezes levar-nos a proteger-nos dos avanços que fazem progredir a sociedade. Ao procurar ignorar estes aspectos emocionais em vez de reconhecê-los, ficamos mais à sua mercê quando tentamos tomar decisões racionais.
Uma das coisas que achei mais notável desde que escrevi o livro “ Engenharia de Impacto: Transformando além do gerenciamento ágil de projetos ” é como os mais dogmáticos de ambos os lados da divisão de opinião ágil ignoram os aspectos emocionais e psicológicos que de fato constituem a maior parte do o livro e são, como as evidências me mostram, está no cerne de iniciativas de transformação verdadeiramente bem-sucedidas.
Isto constitui um lembrete claro de que, antes de irmos demasiado fundo na toca do coelho, temos de nos lembrar que as lições da ciência e da engenharia são que o questionamento da ortodoxia e a recolha de provas estão no cerne de descobertas verdadeiramente notáveis.