Desingeniería ágil

Cómo un movimiento creado para liberar a los ingenieros terminó erosionando la cultura de ingeniería en la gran empresa

Publicado por Polity | Junio de 2026
Autores: Alexandre Kotcherguine, Vision Officer & Investor, Polity;
Kevin Riedl, Managing Partner, Wavect GmbH

Este artículo trata sobre metodología de desarrollo de software y diseño organizativo. Se apoya en fuentes públicas, incluidos los escritos de los propios firmantes del Manifiesto Ágil, y en la literatura empírica de ingeniería de software. Nada de lo que contiene constituye asesoramiento profesional, jurídico o de inversión.

Resumen ejecutivo

En 2001, diecisiete ingenieros firmaron el Manifiesto por el Desarrollo Ágil de Software como una rebelión contra los procesos pesados y orientados al control de las décadas anteriores. Era una defensa del oficio, del software que funciona y de quienes lo escriben. Dos décadas después, varios de esos mismos autores han renegado públicamente de aquello en lo que se ha convertido la palabra. Este artículo sostiene que lo que hoy practican muchas grandes organizaciones bajo la bandera de Agile equivale con frecuencia a una desingeniería: la eliminación progresiva de las disciplinas técnicas, la holgura arquitectónica y el criterio artesanal que hacen posible un software duradero, mientras se conservan intactas las ceremonias visibles. Recurre al testimonio de los propios firmantes, Thomas, Jeffries, Fowler y Cunningham, y a un canon más amplio que abarca a Taylor y al historiador del trabajo Ensmenger, a Goodhart y Strathern, a Conway y DeMarco, y al programa de investigación DORA. De ahí surge un mecanismo reconocible: un movimiento artesanal es capturado como marca; se conservan sus rituales auditables mientras se descartan sus lentas prácticas de ingeniería; sus herramientas de previsión se convierten en instrumentos de presión; y todo ello se impone de arriba abajo a una escala para la que nunca fue diseñado. La objeción más fuerte, que las prácticas de ingeniería han demostrado empíricamente impulsar el rendimiento, se examina de frente y acaba apoyando la tesis en lugar de refutarla. Las secciones finales recuperan la lección que los firmantes llevan casi dos décadas intentando transmitir: la cura para la desingeniería no es un framework mejor, sino restaurar la propia cultura de ingeniería.

El Manifiesto era un documento de ingeniería

Recordemos a qué se comprometieron realmente los autores originales. El Manifiesto establecía cuatro preferencias de valor: individuos e interacciones sobre procesos y herramientas, software funcionando sobre documentación exhaustiva, colaboración con el cliente sobre negociación contractual y respuesta al cambio sobre seguimiento de un plan. Al mismo tiempo afirmaba expresamente que los elementos de la derecha también tenían valor. El documento reaccionaba a los problemas del desarrollo tal y como se practicaba entonces y buscaba un terreno común entre metodólogos rivales (1).

Lo decisivo es que el movimiento no llegó con las manos vacías en el terreno de la ingeniería. Varios firmantes procedían directamente de Extreme Programming (XP), una disciplina definida por el desarrollo guiado por pruebas, la integración continua, la programación en pareja, el refactoring y la propiedad colectiva del código. Kent Beck, su principal autor, explicó que uno de sus objetivos al crear XP era hacer más seguro el entorno de trabajo del programador. Ron Jeffries, colaborador suyo y también firmante, ha vuelto repetidamente sobre ese punto. Ward Cunningham, otro de los diecisiete, ya había dado al campo su concepto más duradero de prudencia técnica: la deuda técnica. La metáfora sostiene que un poco de código no del todo correcto acelera la entrega solo mientras se amortice pronto mediante su reescritura, y que una organización que nunca paga puede quedar paralizada por los intereses acumulados (2). La agilidad, en su forma fundacional, era inseparable de la práctica técnica. La ligereza del proceso debía ganarse mediante la solidez de la ingeniería que había debajo.

La palabra se convirtió en marca, y la marca se vendió

Según el testimonio de los propios autores, el declive comienza cuando agile dejó de ser un adjetivo que describía cómo se trabajaba y pasó a ser un sustantivo que podía comprarse, certificarse y desplegarse. En 2014, el firmante Dave Thomas publicó “Agile is Dead (Long Live Agility)”. Sostenía que la palabra se había convertido en un imán para cualquiera con horas que facturar o productos que vender, degradada a etiqueta de marketing como eco o natural. Contaba que se había mantenido deliberadamente lejos de la industria Agile, comparaba las conferencias sobre agilidad con conferencias sobre bailar ballet y un organismo sectorial construido en torno a cuatro valores con un sindicato para gente que respira. Su objeción gramatical contenía una acusación de fondo: “do Agile right” tiene tan poco sentido como “do orange right”, porque la agilidad es una cualidad de la conducta, no un producto que se instala (3).

Este es el primer mecanismo de la desingeniería: la comercialización. Un movimiento creado por profesionales para proteger a profesionales se convirtió en una economía de certificaciones donde quienes vendían el método a menudo no eran quienes escribían el código. El duro trabajo de ingeniería, dijo Thomas en charlas posteriores, lo siguen haciendo las propias empresas. Las consultoras, como en la fábula de la sopa de piedra, suelen aportar poco más que la olla.

“Dark Agile”: cuando el nombre se vuelve contra los ingenieros

Si Thomas describió la dilución comercial, Ron Jeffries describió algo más grave. En 2018 aconsejó a los desarrolladores abandonar “Agile”, la versión con mayúscula y convertida en marca, y volver a los valores subyacentes. Distinguió “Faux Agile” y “Dark Agile”, además de “Dark Scrum” para el framework dominante, para nombrar aquellas formas que, según él, empeoraban la vida de los desarrolladores en vez de mejorarla. Era la inversión exacta de la intención fundacional de XP. Su diagnóstico merece decirse con claridad: cuando las ideas Agile se aplican mal, tienden a producir más interferencia con los desarrolladores, menos tiempo para hacer el trabajo, mayor presión y una exigencia permanente de la dirección para ir más rápido (4).

Martin Fowler, otro firmante, expuso el mismo punto desde el escenario de una conferencia aquel año. La lucha ya no consistía en convencer a la gente para que adoptara Agile, sino en enfrentarse al faux-agile: Agile de nombre, sin sus prácticas ni sus valores. Peor que fingir, señaló, era usar activamente la palabra agile contra los principios que debía defender (5). Dos de los diecisiete de Snowbird habían llegado de forma independiente a la misma conclusión: la etiqueta había sido capturada, y quienes más sufrían la captura eran los ingenieros a los que debía servir.

No es solo la decepción de los fundadores. El patrón también aparece en los datos de los profesionales. Las encuestas anuales de estilo State of Agile señalan que el principal obstáculo para la adopción no es técnico, sino cultural. En 2023, casi la mitad de los encuestados mencionó la resistencia general de la organización al cambio o un choque de culturas como razón por la que el lado de negocio no abrazaba Agile, una proporción que crecía año tras año. La prensa especializada documentó hasta 2024 el efecto paralelo: Agile perdía popularidad en las grandes empresas, con el burnout de los desarrolladores como factor central y el “seguimiento de culto” del método abiertamente cuestionado. Cuando quienes viven el despliegue hablan de choque cultural y agotamiento en vez de desacuerdo técnico, el diagnóstico de los firmantes queda confirmado desde abajo.

Las prácticas eran opcionales, así que fueron lo primero en desaparecer

Este es el fallo estructural que impulsa la desingeniería. Las partes visibles y gestionables de Agile, stand-ups, sprints, backlogs, story points y gráficos de velocity, son baratas de imponer y fáciles de auditar. Las partes que realmente aportan calidad de ingeniería, desarrollo guiado por pruebas, integración continua, refactoring, pairing y mantenimiento deliberado de la salud del código, tardan en aprenderse, son invisibles para los gestores no técnicos y no producen una ceremonia inmediata. Cuando una organización adopta el framework pero no el oficio, conserva los rituales y descarta la ingeniería. Jeffries observó que algunos equipos renuncian a aprender las prácticas técnicas porque esperan que no aporten beneficio. Las abandonan antes de experimentar su valor y luego interpretan su ausencia como prueba de que eran prescindibles.

La metáfora de Cunningham explica la consecuencia con incómoda precisión. Sin refactoring ni disciplina de pruebas, cada sprint entrega un poco más de código no del todo correcto. La deuda nunca se paga. Los intereses se acumulan porque cada cambio posterior se vuelve más lento y peligroso. La organización llega así, mediante una secuencia de decisiones localmente razonables, al estancamiento que Cunningham advirtió. “Software funcionando sobre documentación exhaustiva” se interpreta como permiso para no escribir ni pruebas ni documentos. “Responder al cambio” se convierte en licencia para una alteración perpetua del alcance sin holgura arquitectónica que pueda absorberla. Precisamente las disciplinas diseñadas para contener la deuda técnica parecían opcionales y fueron eliminadas.

El estancamiento ya no es una metáfora, sino una partida contable. El Developer Coefficient de Stripe de 2018, basado en unos 3.000 desarrolladores, concluyó que el ingeniero medio dedica aproximadamente 13,5 horas de cada semana laboral a la deuda técnica y otras 3,8 horas al código deficiente. Cerca del 42 por ciento de la semana no se emplea en construir nada nuevo. El informe valoró esa producción global perdida en unos 85.000 millones de dólares anuales (6). La investigación de McKinsey sobre deuda tecnológica coloca el mismo fenómeno en el balance: los CIO encuestados estimaron que la deuda técnica equivale al 20 o 40 por ciento del valor total de su patrimonio tecnológico antes de depreciación, y que una quinta parte del presupuesto asignado nominalmente a nuevos productos se desvía en silencio a mantenerla (7). El Consortium for Information & Software Quality estimó en 2022 que las empresas estadounidenses acumulaban unos 1,52 billones de dólares en deuda técnica, dentro de un coste total de mala calidad del software de 2,41 billones (8). Las cifras son necesariamente imprecisas y los proveedores que encargan los estudios tienen interés en alarmar. Sin embargo, su orden de magnitud queda corroborado por trabajos independientes y describe exactamente el interés compuesto que Cunningham nombró en 1992. Las disciplinas que descarta la desingeniería eran las que mantenían esa cifra bajo control.

La medición reutilizada: Goodhart dentro del sprint

El segundo mecanismo consiste en convertir herramientas de previsión en instrumentos de control. Los story points y la velocity nacieron como ayudas aproximadas y relativas a cada equipo para planificar. En cuanto se convierten en objetivos de gestión entra en juego la ley de Goodhart. En la formulación ampliamente citada de la antropóloga Marilyn Strathern sobre el economista Charles Goodhart: “when a measure becomes a target, it ceases to be a good measure.” (9) Si se premia la velocity, una tarea estimada honestamente como tres se convierte en cinco. Las estimaciones se inflan, la comparación entre equipos pierde sentido y el número deja de reflejar la capacidad que pretendía describir. No es deshonestidad, sino optimización racional por parte de personas sometidas a medición. Es el mismo efecto estructural que Goodhart observó cuando los bancos centrales empezaron a fijar como objetivo los agregados monetarios que hasta entonces habían servido como indicadores útiles (10).

El propio hombre que enseñó al campo a medir ya había lanzado la advertencia. Tom DeMarco, cuyo dictamen de 1982 “you can’t control what you can’t measure” marcó a una generación de gestión de software, se retractó públicamente en 2009. Concluyó que los proyectos de software son fundamentalmente experimentales, no controlables, y que la orientación a métricas que él había defendido había distraído a la disciplina de la única pregunta que importa: si el software transforma algo valioso. Cuando el autor del paradigma de control reniega de él, la empresa guiada por velocity sigue aplicando un método abandonado por su propio arquitecto (11).

Escalar nunca fue el objetivo, pero en la gran empresa todo es escala

Un tema recurrente en los comentarios posteriores de los fundadores es que la agilidad fue concebida para equipos pequeños, próximos y autónomos, no para miles de personas coordinadas mediante una jerarquía corporativa. Thomas ha señalado que mil personas trabajando en una sola cosa nunca pueden ser ágiles en el sentido original, y que una empresa debe volverse ágil antes de que pueda serlo cualquiera de sus proyectos. El incentivo comercial apuntaba en la dirección contraria: los mayores ingresos estaban en frameworks de escalado como SAFe, LeSS y sus variantes, vendidos precisamente a las organizaciones grandes y jerárquicas menos adecuadas para la idea original.

Jeffries identificó la consecuencia directamente. Los despliegues a gran escala suelen decidirse arriba e imponerse hacia abajo, obligando a la mayoría del personal a adoptar el nuevo proceso sin formación adecuada ni comprensión de la mentalidad que lo sustenta. Lo que llega al ingeniero es, por tanto, la inversión exacta del primer valor del Manifiesto: no individuos e interacciones, sino un proceso y una herramienta obligatorios entregados desde arriba. La ley de Conway afina el punto. La observación de Melvin Conway de 1968, según la cual la arquitectura de un sistema termina reflejando la estructura de comunicación de la organización que lo construye, implica que una organización rígida, jerárquica y atada a ceremonias tenderá a producir software rígido, frágil y cargado de deuda, por muchos carteles de Agile que tenga en la pared. El framework escala la ceremonia, pero no puede escalar el criterio. La arquitectura registra la diferencia (12).

La objeción más fuerte: pero las prácticas son mediblemente eficaces

La objeción más seria no procede de las consultoras, sino del mejor trabajo empírico del campo y merece formularse con toda su fuerza. El programa DORA de Nicole Forsgren, Jez Humble y Gene Kim, basado en las encuestas State of DevOps y sintetizado en Accelerate (2018), aplicó métodos estadísticos rigurosos a decenas de miles de respuestas. Demostró que precisamente las capacidades técnicas que este artículo denomina “el oficio”, integración continua, automatización de pruebas, desarrollo sobre trunk y arquitectura débilmente acoplada, no son preferencias blandas, sino impulsores medibles tanto del rendimiento de entrega como de los resultados organizativos (13). Si se puede demostrar que la disciplina de ingeniería da resultados, sostiene la objeción, el mercado la elegirá y hablar de “desingeniería” es un pesimismo fuera de lugar.

La objeción acierta en los hechos y precisamente por eso respalda la tesis. DORA demuestra que las disciplinas descartadas son las que funcionan. Su abandono constituye una acusación más grave contra los frameworks impuestos, no una menor. Los propios responsables del programa han hablado con inusual franqueza sobre el modo de fallo. En octubre de 2023, el equipo DORA advirtió explícitamente contra el uso de sus cuatro métricas para comparar equipos, justo la aplicación que las empresas adoptaron con mayor entusiasmo. Una investigación independiente del informático Junade Ali con la encuestadora Survation concluyó que ingenieros y usuarios valoraban más que las métricas de velocidad otros factores que las cuatro claves no capturan. La lección coincide con todo lo anterior: una buena medida de capacidad, elevada a objetivo entre equipos, se degrada por la ley de Goodhart exactamente igual que la velocity. DORA no autorizó la fijación métrica que las empresas practican en su nombre, sino que advirtió contra ella. Medir lo correcto y convertirlo en objetivo son actos distintos. En la distancia entre ambos vive la desingeniería.

El patrón profundo: la gestión científica regresa vestida de Agile

Demos un paso atrás. La forma resulta familiar porque es anterior al software. Principles of Scientific Management de Frederick Winslow Taylor (1911) prescribía tres movimientos que todavía definen la gestión industrial: descomponer el trabajo en unidades medibles, estandarizar el flujo de trabajo y, el decisivo, separar la planificación de la ejecución, retirando el criterio al trabajador y concentrándolo en la dirección (14). El historiador Nathan Ensmenger muestra en The Computer Boys Take Over (2010) que este fue exactamente el programa aplicado a la programación (15). Documenta cómo un oficio celebrado en los años cincuenta como “black art” fue redefinido desde la NATO Conference on Software Engineering de 1968 como “too artistic” y racionalizado deliberadamente. Según su relato, la propia acuñación de “software engineering” fue una respuesta de la dirección a una supuesta crisis de control sobre una fuerza laboral indisciplinada y cara. El movimiento contemporáneo de la “software factory” hizo explícita la ambición taylorista: la propuesta de Douglas McIlroy en 1968 de componentes de software producidos en masa y pedidos por catálogo (16), junto con las fábricas industriales de software que después construyeron Hitachi, Toshiba, NEC y Fujitsu, buscaban convertir la programación de una forma artística en una cadena de suministro “repeatable, scientifically managed” (17).

La ironía histórica del Agile empresarial es que ha reconstruido este mismo paradigma bajo la bandera de un movimiento fundado para escapar de él. Los procesos pesados y divididos en fases fueron la primera herencia de Taylor para la industria del software. El Manifiesto se rebeló contra ellos. Dos décadas después, el Agile escalado y ceremonialmente rígido los ha restaurado en silencio. El sprint se convierte en cronómetro, el story point en unidad de tiempo y movimiento, el burndown chart en libro del capataz y la “velocity” devuelve a la dirección precisamente el control que “individuals and interactions over processes and tools” pretendía desalojar. El mecanismo incluso reproduce la separación característica de Taylor entre planificación y ejecución: el despliegue desde arriba decide el proceso; el ingeniero se limita a ejecutarlo. Por eso el resultado viola tan a menudo el primer valor del Manifiesto mientras ondea su bandera. La posición exige precisión porque puede confundirse con una defensa de no tener proceso alguno. El argumento no es que planificar, medir o coordinar sean ilegítimos. El software a gran escala necesita las tres cosas, y la división del trabajo que implican es, desde Adam Smith, la base de la empresa productiva. El problema aparece cuando el aparato de medición se separa del criterio artesanal y se convierte en instrumento de ritmo. Entonces deja de medir la ingeniería y empieza a reprimirla. La retractación de DeMarco admite, en último término, que el paradigma de control confundió una actividad creativa y experimental con una determinista, y que el error resultó especialmente caro allí donde se aplicó con más confianza.

Qué significa realmente “desingeniería”

Al reunir los hilos, la desingeniería ágil no es el fracaso de una idea, sino la supervivencia de su envoltorio después de vaciar su sustancia. Avanza mediante una secuencia reconocible:

1. Comercialización. El método se convierte en producto, certificado, escalado y vendido por personas distintas de quienes escriben el software.
2. Captura ritual. Se conservan las ceremonias auditables; las disciplinas de ingeniería lentas e invisibles, pruebas, refactoring e integración, desaparecen en silencio.
3. Inversión métrica. Las ayudas de previsión, puntos, velocity e incluso las cuatro claves de DORA, se convierten en objetivos. La ley de Goodhart las degrada a instrumentos de ritmo.
4. Imposición a escala. Se obligan frameworks de escalado desde arriba en organizaciones para las que el método nunca fue diseñado. El personal recibe proceso sin mentalidad.
5. Erosión del oficio. La deuda técnica se acumula sin pagar, la arquitectura se osifica con la forma de la jerarquía según Conway y el estancamiento que advirtió Cunningham llega una decisión razonable cada vez.

Cada paso es racional en lo local y corrosivo en conjunto. Nadie decide desingenierizar. Es el resultado emergente de optimizar lo visible y facturable frente a lo técnico y lento. No es un fallo moral de ningún gestor individual. Como todo efecto Goodhart, es una propiedad estructural de la arquitectura de incentivos, exactamente el tipo de comportamiento sistémico que el criterio artesanal existe para contrarrestar y que los frameworks impuestos eliminan de forma sistemática.

La recuperación no es un framework nuevo

Resulta revelador que los fundadores que diagnosticaron el problema no pidieran un Agile 2.0. Thomas sostuvo expresamente que un segundo manifiesto sería un error trágico. La respuesta no es otro sustantivo que pueda convertirse en marca y venderse, sino volver a la forma de pensar subyacente: entregar pequeños incrementos de software que funcione de verdad, mantener cortos los ciclos de feedback y, sobre todo, restablecer las prácticas técnicas que impulsaban la agilidad desde el principio. La receta de Jeffries es igual de concreta y poco grandilocuente: trabajar en partes pequeñas, ser honesto sobre la capacidad real de entrega y resistir la presión de limitarse a ir más rápido. La de DeMarco es aún más radical: cuestionar por qué tantos proyectos de poco valor se ejecutan bajo un control estricto, en vez de seguir perfeccionando el control.

La lección para la gran empresa es incómoda. La cura para la desingeniería no es un tablero más limpio, un nivel superior de certificación ni un despliegue más fiel del framework. Es restaurar la cultura de ingeniería: el oficio, la holgura y el criterio profesional que los firmantes originales suponían que siempre existirían bajo la palabra. Si se eliminan, solo queda ceremonia: el stand-up diario sobre unos cimientos vacíos, el gráfico de velocity subiendo mientras la arquitectura se pudre. Los autores del Manifiesto llevan casi dos décadas intentando decirlo en su propio nombre y contra su propio interés comercial. La empresa ha conservado sobre todo los rituales y ha perdido el sentido. En demasiadas organizaciones grandes, el gran logro de “doing Agile” ha sido desingenierizar el desarrollo de software mientras creían perfeccionarlo.

La crisis financiera de 2008 y 2009 enseñó a una generación que los modelos elegantes se vuelven peligrosos cuando pasan de herramientas a dogmas. La historia del Agile empresarial enseña la misma lección en una disciplina vecina: un método no se vuelve peligroso cuando es erróneo, sino cuando sus ceremonias sobreviven al oficio que les daba sentido.

Acerca de Polity

Este artículo forma parte de un programa continuo de publicaciones sobre gobernanza y liderazgo intelectual desarrollado dentro del modelo de gobernanza de Polity. La tesis central de Polity es que los resultados duraderos, tanto en mercados como en organizaciones, están determinados por la arquitectura de gobernanza: las reglas, incentivos e instituciones mediante los que se forman el trabajo, el valor y la obligación. La ingeniería de software es un problema de gobernanza en este sentido, y la desingeniería descrita aquí ocurre cuando la arquitectura de incentivos de una organización premia lo visible por encima de lo duradero. Polity construye infraestructura para las finanzas digitales reguladas, con marcos de gobernanza diseñados para conectar sistemas descentralizados y requisitos de cumplimiento de nivel institucional.

Acerca de Wavect

Wavect GmbH es una agencia austriaca de ingeniería de software que construye software orientado a producto para startups, scale-ups y grandes empresas. Su trabajo abarca desarrollo full-stack, liderazgo fraccional de ingeniería y producto, aseguramiento de calidad de software y aplicaciones de inteligencia artificial, blockchain y sistemas zero-knowledge. Wavect ha prestado servicios de desarrollo de software y aseguramiento de calidad al programa Polity, y el coautor Kevin Riedl es Managing Partner de la empresa. Más información en https://wavect.io.

Aviso: Este artículo se publica únicamente con fines informativos y educativos. No constituye asesoramiento profesional, jurídico, financiero ni de gestión de ingeniería, ni respalda metodología, producto, servicio u organización alguna. Las referencias al Manifiesto Ágil y sus firmantes, a investigadores, frameworks, empresas y publicaciones de terceros se incluyen exclusivamente para análisis y comentario. Su inclusión no implica respaldo ni afiliación por parte de Polity. El coautor Kevin Riedl es Managing Partner de Wavect GmbH, que presta servicios de desarrollo de software y aseguramiento de calidad al programa Polity, véase “Acerca de Wavect”. Esta relación comercial se declara por transparencia y no afecta a la independencia del análisis. Las opiniones expresadas pertenecen a los autores.

Referencias

1. Beck, K. et al. (2001) Manifesto for Agile Software Development. Available at: https://agilemanifesto.org (Accessed: 23 June 2026).
2. Cunningham, W. (1992) ‘The WyCash portfolio management system’, OOPSLA ’92 Experience Report. (Origin of the ‘technical debt’ metaphor.) Available at: https://c2.com/doc/oopsla92.html (Accessed: 23 June 2026).
3. Thomas, D. (2014) ‘Agile is dead (long live agility)’. Available at: https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html (Accessed: 23 June 2026).
4. Jeffries, R. (2018) ‘Developers should abandon Agile’. Available at: https://ronjeffries.com/articles/018-01ff/abandon-1/; see also the ‘Dark Scrum’ collection: https://ronjeffries.com/categories/dark-scrum/ (Accessed: 23 June 2026).
5. Fowler, M. (2018) ‘The state of agile software in 2018’. Available at: https://martinfowler.com/articles/agile-aus-2018.html (Accessed: 23 June 2026).
6. Stripe and Harris Poll (2018) The Developer Coefficient: Software Engineering Efficiency and Its $3 Trillion Impact on Global GDP. Available at: https://stripe.com/files/reports/the-developer-coefficient.pdf (Accessed: 23 June 2026).
7. McKinsey & Company (2020) ‘Tech debt: reclaiming tech equity’. Available at: https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/breaking-technical-debts-vicious-cycle-to-modernize-your-business (Accessed: 23 June 2026).
8. Consortium for Information & Software Quality (2022) The Cost of Poor Software Quality in the US: A 2022 Report. (Author: H. Krasner.) Available at: https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/ (Accessed: 23 June 2026).
9. Strathern, M. (1997) ‘“Improving ratings”: audit in the British university system’, European Review, 5(3), pp. 305-321. Available at: https://doi.org/10.1017/S1062798700002660 (Accessed: 23 June 2026).
10. Goodhart, C.A.E. (1975) ‘Problems of monetary management: the UK experience’, in Papers in Monetary Economics, Reserve Bank of Australia. Available at: https://doi.org/10.1007/978-1-349-17295-5_4 (Accessed: 23 June 2026).
11. DeMarco, T. (2009) ‘Software engineering: an idea whose time has come and gone?’, IEEE Software, 26(4), pp. 95-96. Available at: https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf (Accessed: 23 June 2026).
12. Conway, M.E. (1968) ‘How do committees invent?’, Datamation, 14(4), pp. 28-31. Available at: https://www.melconway.com/Home/Conways_Law.html (Accessed: 23 June 2026).
13. Forsgren, N., Humble, J. and Kim, G. (2018) Accelerate: The Science of Lean Software and DevOps. Portland: IT Revolution Press. Available at: https://itrevolution.com/product/accelerate/ (Accessed: 23 June 2026).
14. Taylor, F.W. (1911) The Principles of Scientific Management. New York: Harper & Brothers. Available at: https://www.gutenberg.org/ebooks/6435 (Accessed: 23 June 2026).
15. Ensmenger, N. (2010) The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise. Cambridge, MA: MIT Press. (On the “black art” of programming, the 1968 NATO conference, and the rationalisation of programming labour.) Available at: https://doi.org/10.7551/mitpress/9780262050937.001.0001 (Accessed: 23 June 2026).
16. McIlroy, M.D. (1968) ‘Mass-produced software components’, in Naur, P. and Randell, B. (eds.) Software Engineering: Report on a Conference Sponsored by the NATO Science Committee. Brussels: NATO Scientific Affairs Division, pp. 138-155. Available at: https://www.cs.dartmouth.edu/~doug/components.txt (Accessed: 23 June 2026).
17. Cusumano, M.A. (1991) Japan’s Software Factories: A Challenge to U.S. Management. New York: Oxford University Press. (On the industrialisation of programming via the “software factory”.) Available at: https://global.oup.com/academic/product/japans-software-factories-9780195062168 (Accessed: 23 June 2026).

Fuentes de prensa y web (numeradas para verificar los hechos)

Cuando el texto atribuye una afirmación concreta a un autor identificado, la fuente primaria figura arriba en «Referencias». Los elementos siguientes documentan la información secundaria y los datos de encuestas utilizados, junto con los puntos que respaldan.

• InfoQ (2018). ‘Ron Jeffries says developers should abandon “Agile”.’ “Faux/Dark Agile”; enterprise-vs-developer asymmetry; imposition via SAFe/LeSS. infoq.com/news/2018/06/developers-should-abandon-agile
• pragdave (2014). ‘Agile is Dead (Long Live Agility).’ Noun-vs-adjective argument; “marketing term”; ballet/trade-union analogies. pragdave.me
• Martin Fowler (2018). ‘The State of Agile Software in 2018.’ “faux-agile”; the name used against its own principles. martinfowler.com/articles/agile-aus-2018.html
• Wikipedia (2026). ‘Technical debt.’ Cunningham’s 1992 origin and the “standstill” quotation; extension of the metaphor to architecture and social structures. en.wikipedia.org/wiki/Technical_debt
• Chaco Canyon Consulting (2019). ‘Conway’s Law and Technical Debt.’ Conway’s 1968 Datamation observation; architecture mirrors communication structure. chacocanyon.com/pointlookout/190130.shtml
• Ensmenger, N. (2010), The Computer Boys Take Over (MIT Press), and the “black art” chapter; programming reframed as “too artistic” at the 1968 NATO conference and rationalised thereafter; software engineering as a management response to a crisis of control. Author’s companion site: thecomputerboys.com
• Laws of Software Engineering (2026). ‘Goodhart’s Law.’ Strathern phrasing; velocity, coverage and bug counts as gamed targets. lawsofsoftwareengineering.com/laws/goodharts-law
• Java Code Geeks (2026). ‘We have been measuring developer productivity wrong for forty years.’ LOC → velocity history; estimate inflation (“a 3 becomes a 5”); cross-team comparison breakdown. javacodegeeks.com
• InfoQ (2009) and IEEE Software (2009). DeMarco, ‘Software Engineering: An Idea Whose Time Has Come and Gone?’ Recantation of “you can’t control what you can’t measure”; software as experimental/uncontrollable; primacy of transformation. infoq.com/news/2009/08/demarco-software-engineering
• Wikipedia (2026). ‘DevOps Research and Assessment.’ DORA’s October 2023 warning against team-by-team comparison; Junade Ali / Survation findings on factors beyond the four key metrics. en.wikipedia.org/wiki/DevOps_Research_and_Assessment
• IT Revolution / dora.dev (2018-2026). Accelerate research scope (four years; 23,000+ respondents; 2,000+ organisations); the four key metrics and their capability drivers. dora.dev/resources
• DevClass (2024). ‘Enterprises struggle with Agile methodology.’ Practitioner survey: organisational resistance / culture clash cited by ~half, rising year on year. devclass.com
• IT Pro (2024). ‘Agile development is fading in popularity at large enterprises, and developer burnout is a key factor.’ itpro.com
• The Agile Revolution Podcast, Ep. 119 (2016). Dave Thomas interview: “1,000 working on one thing can never be agile”; enterprise must become agile before any project can be. theagilerevolution.com
• Smartpedia, t2informatik (2025). ‘What is Technical Debt.’ Cunningham as one of the 17 Manifesto authors; taxonomy of debt including Conway-driven “service debt”. t2informatik.de/en/smartpedia/technical-debt
• Stripe / Harris Poll (2018). The Developer Coefficient (survey of ~3,000 developers). 13.5 hrs/week on technical debt and 3.8 hrs on bad code (~42% of the week); ~$85bn global opportunity cost. stripe.com/files/reports/the-developer-coefficient.pdf
• McKinsey & Company (2020). ‘Tech debt: reclaiming tech equity.’ CIOs estimate tech debt at 20-40% of technology-estate value before depreciation; ~20% of new-product budget diverted to servicing it. mckinsey.com
• CISQ (2022). The Cost of Poor Software Quality in the US: A 2022 Report (H. Krasner). Accumulated US technical debt ~$1.52tn; total cost of poor software quality ~$2.41tn. it-cisq.org