Agile es el rigor mortis como religión estatal del software

No ha sido raro en el mundo de la ingeniería de software escuchar proclamaciones de la muerte de Agile de parte de personas con un interés personal en la metodología, afirmando que a menos que mostremos una mayor creencia, se perderá, y en los casos en que falla, simplemente no se ha implementado correctamente , lo que recuerda otras afirmaciones que siguen a la falacia del "no existe un verdadero escocés" como "el comunismo real nunca se ha probado".

A pesar de su presencia en catástrofes de software que van desde errores judiciales hasta desastres de software de aviación, la realidad es que Agile ha mantenido una posición como una especie de religión profesional de la ingeniería de software.

Esta situación ha cambiado profundamente en los últimos meses. Desde que trabajé en una investigación hace seis meses que demostraba que los proyectos de software ágiles tenían una tasa de fracaso un 268 % mayor , han surgido una gran cantidad de investigaciones que corroboran este trabajo.

Al igual que el comunismo o la curación por la fe, las fantasías de grandeza que sostienen que soluciones universalmente buenas, pero poco realistas, pueden resolver todos nuestros problemas siempre atraerán a algunos a pesar de la evidencia, pero lo que ahora ha cambiado fundamentalmente es que existe un consentimiento informado sobre si seguir Agile o hacer algo diferente.

(Sin duda, las noticias internacionales asociadas con la fallida actualización del software de CrowdStrike ciertamente ayudaron a enfatizar los puntos que estaba tratando de plantear).

A pesar del repugnante grado en que algunos en la comunidad Agile llegaron a intentar silenciarme para que no hablara sobre Agile, es importante ser magnánimo en la victoria, por lo que no intentaré volver a litigar los argumentos aquí; en cambio, creo que vale la pena discutir los desarrollos recientes y el camino por delante, 6 meses después.

La investigación DORA de Google apuesta por la metodología Agile

JL Partners, a quien encargué la realización de la investigación sobre la tasa de fracaso de Agile, ha tenido unos últimos meses fenomenales. A diferencia de muchos otros que realizan investigaciones con una responsabilidad limitada, ellos ponen a prueba periódicamente sus modelos prediciendo las elecciones. En lo que respecta a las elecciones del Reino Unido, se dieron cuenta de que estaban produciendo algunas de las predicciones más precisas . Las cosas son aún más notables en lo que respecta a las elecciones estadounidenses, como informa Politico :

… JL Partners bien podría terminar siendo uno de los más precisos en sus predicciones preelectorales finales. El modelo final de la firma fue solo uno de los dos que pronosticaron una victoria de Trump y también proyectó que ganaría el Colegio Electoral por 287 a 251, el margen de victoria más alto proyectado para Trump por cualquier encuestador. También fue uno de los pocos encuestadores que pronosticó que Trump ganaría el voto popular.

Además, una investigación de RAND Corporation realizada inicialmente para el Departamento de Defensa de EE. UU. ha descubierto que el desarrollo de IA y la metodología Agile no se llevan bien . Además, Synodus (un proveedor de tecnología global que abastece a empresas de Fortune 500 como BOC Aviation, KPMG y Unilever) informa que al alejarse de Agile , descubren que están entregando proyectos entre dos y tres veces más rápido e informan que una aerolínea líder ahorró el 63 % de sus costos de desarrollo.

Esto ocurre a pesar del hecho de que la velocidad y el costo son tradicionalmente métricas asociadas con Agile y LEAN, mientras que el enfoque de Ingeniería de Impacto se centra en el Impacto como métrica principal.

Finalmente, como escribió Colm Campbell en el artículo “ P-Hacking with Dinosaurs ”, las afirmaciones presentadas por la “Mafia Ágil” en respuesta al estudio de tasa de fracaso de Ágil han sido refutadas exhaustivamente, dejando solo ataques personales patéticos.

Sin embargo, quizás una de las áreas de investigación de apoyo más sorprendentes proviene del equipo DORA de Google. El propio DORA tiene sus raíces en el movimiento DevOps, que es en sí mismo una criatura de Agile. Su Informe anual sobre el estado de DevOps para 2024 no ha recibido una cobertura particularmente amplia este año, dado el tiempo que se ha dedicado a la investigación de Agile, pero es interesante ver que también le están dando la espalda a Agile.

Ahora, debo señalar que he criticado la metodología del equipo DORA (desde que cambié de opinión sobre Agile, DevOps, etc.) ya que las métricas principales que utilizan para medir las cosas se centran en la velocidad de entrega ( que sabemos que no es lo que los usuarios quieren ), pero el hecho de que estén viendo esto incluso usando su enfoque apunta a que algo más profundo está sucediendo aquí.

En la página 64 del Informe sobre el estado de DevOps 2024, afirman:

'El manifiesto Agile aboga por un software funcional en lugar de una documentación exhaustiva. Sin embargo, seguimos pensando que la documentación de calidad es un componente clave del software funcional.'

Además, en la página 82, parecen darle la espalda al propio DevOps:

'Estamos comprometidos con los principios fundamentales que siempre han sido parte del movimiento DevOps: cultura, colaboración, automatización, aprendizaje y uso de la tecnología para alcanzar objetivos comerciales. Nuestra comunidad e investigación se benefician de las perspectivas de diversos roles, incluidas personas que tal vez no se identifiquen con la etiqueta "DevOps". Es de esperar que el término "DevOps" deje de ser un tema de interés.'

Todavía tengo problemas con su metodología de investigación; los criterios de valoración utilizados para medir el éxito se centran en la velocidad y, además, siguen abogando por un liderazgo transformacional a pesar de que la investigación psicológica en esta área cuestiona tales enfoques.

A nivel humano, parece notablemente burdo centrarse tanto en intentar transformar organizaciones y personas sin su consentimiento informado y al mismo tiempo no reconocer que a menudo no hay mejor fuente de aprendizaje que nuestros propios errores (en la medida en que tengamos el consentimiento informado para cometerlos), una crítica clave que tengo de trabajos como The Pheonix Project y The Unicorn Project .

Sin embargo, es notable ver una creciente corroboración de la ingeniería de impacto frente a las métricas tradicionales de Agile y DevOps.

Scrum, TDD y patrones de diseño

Cuando The Register me entrevistó hace unos meses en el artículo “ Estudio de respaldo: las tomas catastróficas sobre Agile enfatizan demasiado las nuevas características ” , no oculté los tres factores con los que tenía problemas en los enfoques modernos de Agile, DevOps y la transformación digital:

1. Enfoques Agile que desestiman los requisitos, a pesar de desastres como el escándalo de Correos y los accidentes del Boeing 737 Max 8 .

   
   

2. Implementaciones de DevOps que priorizan la velocidad de entrega de nuevas características y la recuperación de problemas en lugar de prevenir problemas en primer lugar, a pesar de que las investigaciones muestran que el público clasifica la obtención de las últimas características lo más rápido posible comolo menos importante para ellos cuando usan sistemas informáticos, siendo la seguridad de los datos, la precisión de los datos y la ausencia de errores graves los factores más importantes.

   
   

3. Intentos de transformación organizacional desde abajo sin obtener el consentimiento informado, descuidando la importancia de permitir que las personas aprendan de sus propios errores si tienen el consentimiento informado para cometerlos, con programas que se venden como éxitos seguros que generalmente terminan en una miseria y un fracaso estresantes.

   
   

Cuando comencé a investigar los desastres de software y los ordenadores asesinos (como se informó en Forbes en abril ), estos fueron los tres factores con los que comencé a tener cada vez más desafíos morales. No tenía ningún problema real con los diferentes enfoques de desarrollo de software o técnicas de gestión de proyectos, ya que no veía el mismo vínculo con los estudios de casos de desastre que estaba investigando. No sentí la necesidad de expresar mis opiniones personales como ingeniero con respecto a estos otros asuntos.

Sin embargo, es interesante ver que el radio de explosión se ha ampliado más allá de estas tres áreas iniciales a otros enfoques defendidos por los coautores del Manifiesto Ágil, como Scrum, Desarrollo basado en pruebas (TDD), Programación orientada a objetos (OOP) y Patrones de diseño (por ejemplo, consulte la publicación de LinkedIn de Soumen Sarkar sobre Patrones de diseño ).

No tengo mucho que añadir en este aspecto. Sin embargo, me pregunto si los coautores de Agile no hubieran luchado tanto contra su muerte como religión, si la comunidad de ingeniería de software hubiera sido más amable con sus otras ideas. La cuestión ahora es discutible dado que el estatus religioso de Agile es rigor mortis y todo parece estar en juego: programación orientada a objetos, patrones de diseño, TDD, etc.

Hacia la conciencia de la aversión a la pérdida

Como he pasado una parte relativamente considerable de los últimos meses apareciendo en las portadas de varias publicaciones tecnológicas hablando de Agile y siendo un tema muy discutido en la comunidad en general, tal vez no sea sorprendente tener algunos encuentros extraños. Sin embargo, en su mayor parte han sido encuentros sumamente agradables con personas que se me acercan en público y participan al azar en una discusión sobre Agile.

Sin embargo, hubo un encuentro que me dejó una profunda impresión. Hace unas semanas, iba al Parlamento del Reino Unido para hablar con los responsables políticos sobre varios escándalos tecnológicos que estaba investigando. Nunca he sido muy partidario de tener poder, y siempre me ha parecido curioso que en los bares privados del Parlamento haya carteles que recuerden a las personas que no deben abusar de su poder cuando están ebrias.

Sin embargo, al dar esta charla, no solo estaba bien vestido y más presentable que de costumbre, sino que también estaba frente a un público comprensivo, flanqueado por un miembro del Parlamento y un amigo que resulta ser un consejero del Rey (un abogado de alto rango a quien el monarca le otorga esa distinción por su defensa excepcional).

Una vez que di mi charla y respondí a una serie de preguntas, había un visitante entre el público que empezó a hablar sobre Agile (la charla no había sido sobre Agile). En contraste con mi traje de tres piezas, estaba vestido con una camisa manchada de ketchup y (sin entrar en detalles) no estaba presentable ni tenía conexiones políticas. Empezó diciendo: “¿Puedo darles algunos comentarios?”

Cuando empezó a hablar de Agile, lo miré a los ojos con curiosidad, y él bajó la mirada y dejó de hablar, casi como si se diera cuenta de que ya no estaba en línea y que estaba frente a alguien con sus palabras. Antes de que pudiera responder, un amigo CEO intervino para abordar el tema por mí.

En ese momento me di cuenta de que no me gustaba el poder en un grado que hasta ahora no había comprendido.

Lamentablemente, para este individuo, ya parecía haber sido víctima de quienes le vendían soluciones de transformación infalibles que aparentemente le habían causado dificultades en su propia vida. En estas circunstancias, ¿por qué se siguen defendiendo estas metodologías de transformación?

En términos más generales, ¿por qué Agile no puede funcionar en el mundo real? Con el comunismo, al menos podemos atribuir el fracaso a la codicia, así que ¿cuál es la psicología del fracaso de Agile? La respuesta, en mi opinión, se reduce a un factor psicológico conocido como aversión a la pérdida . Por demanda popular, recientemente escribí un artículo preimpreso sobre el trabajo de Impact Engineering y se centró en el papel que puede desempeñar la conciencia de la aversión a la pérdida en la mitigación del éxito del proyecto.

El artículo, “¿Soy entonces el Dr. Frankenstein? ¿O fuiste un monstruo todo el tiempo?”: Mitigación del fracaso de proyectos de software con metodologías de desarrollo conscientes de la aversión a las pérdidas , concluye de la siguiente manera:

Los estudios de casos han demostrado que los desastres de software pueden convertirse en catástrofes cuando los problemas no se abordan y, en cambio, se ocultan. Los factores psicológicos, siendo uno de los principales la aversión a las pérdidas, pueden incentivar a las organizaciones a seguir este camino a pesar de las desastrosas consecuencias.

Sin embargo, las metodologías de software históricamente han ignorado este factor psicológico, asumiendo en cambio que los humanos querrán abordar los problemas lo antes posible. Investigaciones anteriores de diversas metodologías han encontrado que la seguridad psicológica para plantear y discutir problemas es clave para mejorar la entrega de software. Sin embargo, es sin duda optimista creer que un cambio cultural y psicológico tan significativo se puede lograr en todas las organizaciones. Como hemos visto, incluso entre el Reino Unido y los EE. UU., la seguridad psicológica sigue siendo la mayor diferencia en la práctica de ingeniería entre los dos países.

En este artículo, nos centramos en un camino diferente a seguir. En lugar de intentar lograr un cambio cultural que, en el mejor de los casos, es un desafío, nos centramos en un enfoque más pragmático: limitar los desencadenantes de la aversión a las pérdidas desde el principio mediante requisitos sólidos y, luego, apuntar a la seguridad psicológica donde sea necesaria. En nuestra investigación, el único factor que encontramos que aumentaría la tasa de éxito de un proyecto más que la seguridad psicológica fue tener requisitos claros desde el principio.

En contra de nuestra hipótesis, los resultados indican que el mero hecho de tener requisitos claros, incluso cuando cambian en una fase avanzada del desarrollo o no están alineados con el mundo real, parece tener un papel importante en el éxito de un proyecto de software. Esto sugiere que tener una puerta de entrada antes del inicio de un proyecto para discutir y abordar los problemas, cuando la aversión a las pérdidas es mínima, permite la mayor mejora en las tasas de éxito.

La canción Dr. Frankenstein de RedHook contiene el estribillo: “¿Soy entonces el Dr. Frankenstein? ¿O fuiste un monstruo todo el tiempo?”. En el caso de los proyectos de software catastróficos, este artículo sostiene que los proyectos de software se convierten en desastres cuando los humanos no logran abordar problemas técnicos de menor escala. Las metodologías de ingeniería de software existentes no abordan el hecho de que los humanos no son máquinas y que los factores psicológicos impiden la capacidad de abordar los problemas. Tras identificar este anacronismo en las metodologías existentes, este artículo presenta cómo podemos actuar al respecto mediante el uso de requisitos antes del inicio de un proyecto para brindar la oportunidad de abordar los problemas cuando la aversión a las pérdidas está en su nivel más bajo.