¿Qué pasó con Agile? Una guía para equipos fuera de Estados Unidos

10 min de lectura

Los frameworks están vivos, pero algo murió

El problema que estos frameworks fueron creados para resolver

En las décadas de 1980 y 1990, la mayoría de los proyectos de software seguían la “cascada” — un proceso secuencial tomado de la manufactura. Los analistas recopilaban requisitos durante meses. Los arquitectos diseñaban el sistema completo. Los desarrolladores lo construían. Los testers encontraban los defectos. Años después, el software llegaba a los usuarios.

El término “cascada” proviene del artículo de 1970 de Winston Royce “Managing the Development of Large Software Systems.” Pero Royce presentó el modelo secuencial como un enfoque defectuoso. Su artículo advertía que este método “es riesgoso e invita al fracaso” y abogaba por el desarrollo iterativo con ciclos de retroalimentación.

La industria adoptó exactamente lo que Royce advirtió en contra, y luego lo nombró según su artículo.

En 1985, el Departamento de Defensa de EE.UU. institucionalizó esta mala interpretación en DOD-STD-2167, requiriendo “fases secuenciales de un ciclo de desarrollo de software.” Le tomó al DoD casi una década cambiar de rumbo. En 1994, MIL-STD-498 fomentó explícitamente la “adquisición evolutiva y el desarrollo iterativo e incremental.”

El desarrollo iterativo no es un invento reciente. Gerald Weinberg documentó equipos usando enfoques incrementales ya en 1957 en IBM. Las prácticas que se convirtieron en “ágil” no fueron descubrimientos — fueron redescubrimientos.

El manifiesto, publicado en 2001, capturó esta idea en cuatro declaraciones de valor. Scrum proporcionó un ritmo de iteraciones cortas. Extreme Programming enfatizó las prácticas técnicas: desarrollo guiado por pruebas, programación en parejas, integración continua. Kanban se centró en visualizar el trabajo y limitar el trabajo en progreso.

La pregunta es qué pasó entre esa idea original y la industria de certificación actual.

¿Quién realmente necesitaba estos frameworks?

Los equipos pequeños que construyen productos de software nunca necesitaron frameworks de proceso elaborados. Un equipo de cinco desarrolladores trabajando directamente con clientes, entregando semanalmente, no necesita ceremonias de Scrum para mantenerse alineado. No necesitan las capas de coordinación de SAFe porque no hay nada que coordinar.

Los frameworks surgieron para grandes organizaciones con muchos equipos, interdependencias complejas y capas de gestión alejadas del trabajo real.

El proyecto Chrysler Comprehensive Compensation (C3) demuestra que la ingeniería disciplinada funciona incluso dentro de grandes corporaciones. Iniciado en 1993 como un sistema de nómina para 87.000 empleados, para 1996 el proyecto aún no había impreso un solo cheque de pago después de tres años de desarrollo tradicional. Kent Beck fue traído y, junto con Ron Jeffries, introdujo las prácticas que se convirtieron en Extreme Programming.

Aproximadamente un año después de adoptar XP, el sistema entró en funcionamiento. Funcionó. Las prácticas de ingeniería — no un framework de gestión — convirtieron un proyecto fallido en un sistema funcional.

DaimlerChrysler canceló el proyecto en 2000 después de adquirir Chrysler. Un gerente anunció en la conferencia XP que DaimlerChrysler había “prohibido XP de facto.”

Las prácticas que rescataron el proyecto fueron descontinuadas. No porque fallaran, sino porque no encajaban con la cultura de gestión de la organización adquirente.

La crisis original que nunca terminó

La “crisis del software” fue nombrada en la Conferencia de Ingeniería de Software de la OTAN de 1968 en Garmisch, Alemania. Los proyectos de software consistentemente excedían presupuesto, cronograma, y a menudo no funcionaban en absoluto. Como se explora en Cerrando la Gran Brecha, el malentendido fundamental entre personas técnicas y no técnicas se remonta a este mismo momento.

Edsger Dijkstra, en su conferencia del Premio Turing de 1972:

“La causa principal de la crisis del software es que las máquinas se han vuelto varios órdenes de magnitud más poderosas. Para decirlo claramente: mientras no había máquinas, la programación no era ningún problema; cuando teníamos unas pocas computadoras débiles, la programación se convirtió en un problema leve, y ahora que tenemos computadoras gigantescas, la programación se ha convertido en un problema igualmente gigantesco.”

El desarrollo de software no es manufactura. Es trabajo de diseño que no escala como las líneas de producción. Agregar más personas a menudo hace los proyectos más tardíos, no más rápidos.

Las grandes organizaciones respondieron con técnicas de gestión industrial: más documentación, más puertas de fase, más separación entre pensar y hacer. DOD-STD-2167 y sus imitadores comerciales institucionalizaron exactamente el enfoque que los practicantes sabían que no funcionaba.

La crisis del software en curso — nunca resuelta, aún produciendo las mismas tasas de fracaso documentadas en los años 1960 — crea demanda perpetua de nuevas soluciones de proceso. Cada metodología fallida crea el mercado para su sucesora. (Para más sobre la proximidad de los frameworks de gestión al aceite de serpiente, ver el artículo anterior.)

La ironía es que el Manifiesto Ágil original fue escrito por practicantes que rechazaban explícitamente los enfoques centrados en la gestión. Valoraban “individuos e interacciones sobre procesos y herramientas.” Lo opuesto a lo que la industria de certificación eventualmente vendió.

La línea de tiempo de la desilusión

Dave Thomas, uno de los diecisiete firmantes originales del Manifiesto Ágil, en su artículo de 2014 “Agile is Dead (Long Live Agility)”:

“La palabra ‘ágil’ ha sido subvertida hasta el punto de ser efectivamente sin sentido, y lo que pasa por comunidad ágil parece ser en gran parte una arena para que consultores y vendedores promocionen servicios y productos.”

Las declaraciones públicas de las personas que crearon estos enfoques:

2009: Ken Schwaber, co-creador de Scrum, deja la Scrum Alliance después de desacuerdos sobre “evaluaciones, certificación y un programa para desarrolladores.” Funda Scrum.org al año siguiente.

2013: Schwaber llama a SAFe “unSAFe at any speed”:

“Los chicos de RUP (Rational Unified Process) han vuelto. Construyendo sobre el profundo fracaso de RUP, ahora están impulsando el Scaled Agile Framework como un enfoque simple, de talla única, para la organización ágil.”

2014: Dave Thomas declara “Agile is Dead” y propone retirar el término completamente.

2018: Martin Fowler, en su keynote de Agile Australia:

“Nuestro desafío en este momento no es hacer que ágil sea algo que la gente quiera hacer, es lidiar con lo que llamo pseudo-ágil: ágil que es solo el nombre, pero ninguna de las prácticas y valores implementados.”

Y:

“El Complejo Industrial Ágil imponiendo métodos a las personas es una tragedia absoluta.”

2018: Ron Jeffries publica “Developers Should Abandon Agile”:

“Me gustaría que el mundo fuera seguro para los desarrolladores… me rompe el corazón ver las ideas que escribimos en el Manifiesto Ágil usadas para hacer la vida de los desarrolladores peor, en lugar de mejor.”

Recomienda a los desarrolladores “desconectar su pensamiento de cualquier método ‘Ágil’ nombrado en particular” y acuña “Dark Agile” y “Dark Scrum” para describir implementaciones impuestas y enfocadas en el cumplimiento.

Estos no son críticos marginales. Estos son los arquitectos del movimiento original.

Qué cambió

Los valores originales del manifiesto:

• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan

La industria de certificación descubrió que el lado derecho se vende mejor. Los procesos pueden empaquetarse. Las herramientas pueden licenciarse. La documentación puede justificar facturación. Los planes crean contratos.

El lado izquierdo — individuos, interacciones, colaboración, respuesta al cambio — requiere juicio y contexto. Resiste la estandarización. No escala como producto.

La industria construyó frameworks elaborados alrededor del lado derecho mientras reclamaba el manto del izquierdo.

Por qué esto importa fuera de Estados Unidos

La máquina comercial de frameworks se expandió globalmente con un retraso de aproximadamente cinco a diez años. Los despliegues de SAFe en Europa se aceleraron entre 2015 y 2020. La misma trayectoria que experimentaron los equipos de software estadounidenses se está repitiendo ahora internacionalmente.

Los equipos que aún no se han comprometido con una compra de framework pueden observar lo que pasó sin pagar por la lección.

Los informes 17 y 18 del State of Agile muestran que el 42% de las organizaciones ahora usan modelos híbridos, mezclando prácticas ágiles con enfoques tradicionales. Los equipos descubrieron que la adherencia dogmática a cualquier framework produce peores resultados que la adaptación reflexiva al contexto.

La distinción que importa

Los frameworks siguen siendo útiles como herramientas de diagnóstico. Las ceremonias de Scrum pueden revelar disfunciones. Los patrones arquitectónicos de SAFe pueden exponer fricción de integración. La visualización de Kanban puede hacer visibles los cuellos de botella.

El problema surge cuando el framework se convierte en el objetivo en lugar de la lente. Cuando “hacer Ágil” reemplaza a “entregar valor.”

La pregunta relevante no es “¿Qué framework deberíamos adoptar?” sino “¿Qué capacidad específica necesitamos desarrollar?”

Qué requiere la excelencia en ingeniería

Cuando los autores del manifiesto describen lo que realmente funciona, regresan a las prácticas técnicas: desarrollo guiado por pruebas, integración continua, refactorización, programación en parejas, entrega en lotes pequeños.

Estas prácticas no requieren certificación. No escalan como productos de consultoría. Requieren aplicación disciplinada a lo largo del tiempo.

La crítica de Martin Fowler de 2018 identificó tres desafíos:

1. Luchar contra el “Complejo Industrial Ágil”
2. Elevar la importancia de la excelencia técnica
3. Organizarse alrededor de productos, no de proyectos

Noten lo que falta: selección de framework, patrones de escalamiento, estructuras de gobernanza. El camino hacia adelante no es más metodología. Es mejor ingeniería.

Una postura práctica

Prácticas de ingeniería que producen resultados observables: tiempos de entrega más cortos, tasas de defectos más bajas, recuperación más rápida de incidentes, adopción genuina de usuarios. Estas métricas no les importa qué framework afirmes seguir. Como se discute en Los Frameworks de Gestión No Arreglan Equipos de Software, los frameworks diagnostican síntomas mientras los desarrolladores eliminan causas raíz.

Al evaluar cualquier práctica o transformación propuesta: “¿Qué podremos observar, en producción, que no podemos observar hoy?”

Si la respuesta involucra dashboards, informes o votos de confianza en lugar de software funcionando en manos de usuarios, estás comprando etiquetas en lugar de capacidad.

Los frameworks no están muertos. Pero el contenido semántico que una vez hizo útil a “Ágil” ha migrado a otro lugar: a las prácticas silenciosas de equipos que entregan frecuentemente, responden a la evidencia, y miden el éxito por lo que sus usuarios realmente experimentan.

Para equipos fuera de Estados Unidos navegando estas decisiones ahora: la ceremonia no produce el resultado. La práctica de ingeniería sí.

Una advertencia: las mismas dinámicas de mercado que comercializaron Ágil probablemente producirán alternativas “post-Ágil” dirigidas a mercados en desarrollo. Diferente marca, mismo modelo de negocio — certificaciones, transformaciones, dependencias de consultores. El retraso entre la adopción en EE.UU. y la expansión global crea oportunidades de arbitraje. El escepticismo hacia los incumbentes no debería traducirse en confianza hacia sus críticos convertidos en competidores.

Primero ver por ti mismo

Antes de firmar contratos con consultores de transformación, considera observar lo que realmente está pasando.

La mayoría de los ejecutivos que toman decisiones sobre entrega de software tienen visibilidad limitada del trabajo en sí. Reciben informes de estado, votos de confianza y gráficos de velocidad — ninguno de los cuales revela si el software está llegando a los usuarios o si los equipos están luchando con fricción de integración, requisitos poco claros o deuda técnica.

Caimito Navigator sintetiza lo que tus equipos están realmente haciendo — desde bitácoras diarias y señales de entrega — en información semanal que cualquier gerente no técnico puede entender. No se requiere compra de framework. No se necesita certificación. Hechos observados sobre tu realidad de entrega.

El servicio incluye conversaciones con practicantes experimentados que pueden ayudar a interpretar patrones y sugerir mejoras específicas. Sin presión de compra, sin upselling a programas de transformación.

Muchas organizaciones descubren que sus equipos ya saben qué está roto. Solo necesitan a alguien que haga visible ese conocimiento a los tomadores de decisiones que pueden remover obstáculos. A veces la intervención más valiosa no es un nuevo proceso — es visibilidad del proceso que ya tienes.