Los modelos predictivos dominaron durante décadas, pero la propia industria del software impulsó un cambio de mentalidad. Comprender la evolución histórica facilita explicar por qué los equipos comenzaron a cuestionar la rigidez de los procesos lineales y a explorar alternativas iterativas.
En los años 70, los proyectos informáticos se planificaban como si fuesen obras de ingeniería civil. Se priorizaba anticipar cada detalle antes de escribir una sola línea de código. Este paradigma funcionaba relativamente bien cuando el software automatizaba procesos administrativos estables. Sin embargo, al expandirse a dominios regulados, sistemas distribuidos y productos comerciales, la realidad superó a los supuestos del modelo tradicional.
A finales de los 80, la presión por lanzar soluciones innovadoras reveló que la planificación exhaustiva no garantizaba el éxito. Los proyectos crecieron en tamaño, la tecnología cambiaba rápido y los usuarios demandaban participar en la definición. Con cada fracaso, aumentaba la convicción de que hacía falta pensar el desarrollo de software desde otro enfoque.
El término «crisis del software» describe la brecha entre las expectativas del mercado y la capacidad de entrega de la industria. Informes de la época señalaban proyectos que excedían en un 200% los presupuestos originales, sistemas cancelados antes de salir a producción y soluciones con defectos graves que ponían en riesgo operaciones críticas.
Los factores más citados eran:
La crisis motivó investigaciones académicas, comités gubernamentales y la búsqueda de metodologías capaces de lidiar con el cambio continuo. Las organizaciones comprendieron que la incertidumbre era inherente al desarrollo de software, no una falla del equipo.
El aprendizaje principal de la crisis fue que planificarlo todo al inicio no evitaba los riesgos, solo los posponía. Se empezó a valorar la posibilidad de inspeccionar el producto temprano, ajustar el rumbo con datos reales y fomentar la participación activa del cliente.
En este periodo emergieron conceptos como iteración, prototipo funcional y retroalimentación continua. Las organizaciones comenzaron a dividir los proyectos en entregas parciales y a formar equipos multidisciplinarios que trabajaban en paralelo. La prioridad pasó de cumplir un plan fijo a confirmar que el software resolviera necesidades concretas.
El cambio cultural implicó repensar roles: los analistas debían colaborar con programadores y testers desde el inicio, y los usuarios finales eran invitados a talleres para validar funcionalidades. Esta transición abrió el camino para marcos que hoy llamamos ágiles.
A comienzos de los 90 surgieron propuestas que rompían con la rigidez del ciclo en cascada. Uno de los más citados fue Rapid Application Development (RAD), impulsado por James Martin. RAD proponía ciclos de entrega de 30 a 90 días, uso intensivo de prototipos y equipos pequeños con alto grado de autocontrol. El objetivo era validar ideas rápido y reducir el tiempo entre el pedido del usuario y la entrega.
En paralelo, la comunidad europea desarrolló DSDM (Dynamic Systems Development Method), un marco que combinaba iteraciones con una gobernanza robusta. DSDM introdujo el concepto de priorizar requerimientos usando la técnica MoSCoW (Must, Should, Could, Won’t) y puso el foco en la participación comprometida del usuario. Aunque estos movimientos no eran idénticos, compartían principios: entregas frecuentes, revisiones constantes y flexibilidad en el alcance.
Las organizaciones que adoptaban RAD o DSDM reportaban mayor satisfacción del cliente y descubrían que la documentación seguía siendo valiosa, pero debía adaptarse al ritmo iterativo. Estas experiencias demostraron que era posible mantener disciplina sin sacrificar velocidad.
Mientras RAD y DSDM enfatizaban la gestión del proyecto, los equipos técnicos buscaron mejorar la calidad interna del software. En ese contexto nació Extreme Programming (XP), formalizado por Kent Beck en 1996 durante el desarrollo del sistema Chrysler Comprehensive Compensation.
XP introdujo prácticas radicales para la época: programación en pares, desarrollo guiado por pruebas (Test-Driven Development), integración continua y ciclos de iteración de una o dos semanas. La filosofía era simple: si una práctica aporta valor, llevémosla al extremo para potenciar sus beneficios.
El movimiento demostró que la calidad no era algo que se agregaba al final, sino un atributo que debía construirse desde el primer día. También reforzó la idea de que el cliente debe estar disponible continuamente para responder preguntas y redefinir prioridades. Muchas de estas prácticas se integraron luego en marcos como Scrum y en la cultura ágil en general.
Esta evolución del pensamiento, desde la crisis hasta las propuestas iterativas, preparó el escenario para el encuentro que daría origen al manifiesto ágil en 2001. En el siguiente tema revisaremos cómo estos aprendizajes se cristalizaron en valores y principios compartidos por la comunidad.