Por qué entregamos cada dos semanas y no al final

Lo que aprendimos de proyectos que se entregaron “completos” y nadie usó.

Un patrón se repite en el desarrollo de software a la medida. La empresa describe lo que necesita en un documento, el proveedor desarrolla durante meses y, al final, entrega un sistema “completo”. En ese momento aparecen los problemas: el flujo real del negocio no era el del documento, la persona que más iba a usar el sistema no participó en la definición y hay pantallas que nadie abre. Cuando eso se descubre al final, ya no hay presupuesto ni tiempo para corregirlo.

En GDISIE trabajamos con entregas cada dos semanas. Esto no responde a una moda metodológica. Responde a que es más barato descubrir un error en la semana dos que en el mes seis. Este artículo explica en qué evidencia nos apoyamos, cuál descartamos y qué le pide este modelo a quien nos contrata.

Hasta el “padre de la cascada” lo advirtió

El modelo de cascada (requisitos, diseño, desarrollo, pruebas y entrega, en secuencia) se atribuye a menudo a un artículo de Winston Royce de 1970. Ese artículo, sin embargo, advierte contra esa versión lineal. Tras describirla, Royce escribe que cree en el concepto, “pero la implementación descrita es riesgosa e invita al fracaso”, porque los problemas se descubren cuando el sistema ya está casi terminado [1]. Su propuesta incluía hacer una primera versión piloto (“hazlo dos veces”) e involucrar formalmente al cliente durante todo el desarrollo, no solo al principio y al final [2].

Una cifra que no usamos, y por qué

En presentaciones sobre metodologías ágiles circula la afirmación de que “el 64 % de las funcionalidades de un software rara vez o nunca se usan”, atribuida al Standish Group. Mike Cohn rastreó su origen: Jim Johnson, de Standish, la presentó en la conferencia XP 2002 a partir de un estudio de cuatro aplicaciones internas, ningún producto comercial. Cohn pide expresamente no usarla para afirmar que todo software tiene un 64 % de funciones inútiles [3]. Con los años, algunos libros la ampliaron a “entre 64 y 75 %” sin aportar una fuente primaria nueva [4]. Por eso no la usamos como evidencia, y recomendamos desconfiar de quien la presente como dato general de la industria.

Hay datos más recientes con mejor documentación, aunque también con límites. En su informe de 2019 sobre adopción de funcionalidades, la empresa de analítica Pendo afirma que el 80 % de las funcionalidades del producto de software promedio rara vez o nunca se usa. La base son 615 suscripciones de sus propios clientes, analizadas durante tres meses [5]. Es un proveedor que vende una herramienta para medir precisamente eso, y la muestra está formada por productos SaaS, no por software a la medida para pymes. Lo que sí sostienen ambas fuentes, con todas sus debilidades, es que buena parte de lo que se construye termina usándose poco.

Ni los expertos aciertan a la primera

Una evidencia más sólida viene de la experimentación controlada. Ronny Kohavi, que dirigió la plataforma de experimentación de Microsoft, reportó que en esa empresa aproximadamente un tercio de las ideas probadas mejoró la métrica buscada, un tercio no tuvo efecto y un tercio la empeoró. En general, entre el 60 % y el 90 % de las ideas no mejora la métrica para la que fue diseñada, según el dominio [6]. Un experimento A/B a gran escala no es lo mismo que una revisión quincenal con un cliente, pero el principio sirve para ambos: la intuición sobre qué funcionará falla con frecuencia, y conviene comprobarla pronto y con poco costo.

Lo que no afirmamos

Sería cómodo decir que “los proyectos ágiles tienen más éxito que los de cascada” y citar los informes CHAOS del Standish Group. Preferimos no apoyarnos en ellos. Su metodología no es pública y fue cuestionada en IEEE Software por Eveleens y Verhoef: al aplicar las definiciones de éxito de Standish a más de 1.200 proyectos reales, encontraron que esas cifras no reflejaban la realidad de los casos estudiados [7]. Además, el propio Standish reportó en algunos años que, en proyectos pequeños, la cascada no salía peor que el desarrollo ágil [8], y muchos proyectos de pymes son pequeños.

Nuestro argumento es otro: entregar en ciclos cortos reduce el riesgo de construir lo que no se necesita, porque el cliente ve software funcionando desde temprano y puede corregir el rumbo.

Por qué dos semanas

El Manifiesto Ágil (2001) pide entregar software funcionando con frecuencia, “de un par de semanas a un par de meses”, con preferencia por el periodo más corto [9]. La Guía de Scrum de 2020 establece que los sprints tienen una duración fija de un mes o menos [10]. Dos semanas cabe en ambos marcos y no es una regla. Lo elegimos porque es suficiente para entregar algo que se pueda probar y lo bastante corto para no acumular demasiado trabajo sobre supuestos sin validar.

Hay una base de evidencia de largo plazo sobre el principio de fondo. El programa de investigación DORA, que estudia equipos de tecnología desde 2014, concluye que trabajar en lotes pequeños es esencial donde los ciclos de retroalimentación importan, y que, junto con otras capacidades, predice el desempeño en la entrega de software y el desempeño organizacional [11]. DORA también encontró que velocidad y estabilidad no se contraponen: los equipos con mejor desempeño destacan en ambas [12]. Estos estudios miden despliegues a producción, no entregas a un cliente, así que los tomamos como un principio análogo y no como prueba directa de que los sprints de dos semanas funcionan.

El principio sigue vigente con la llegada de la inteligencia artificial al desarrollo. En su investigación de 2025 sobre desarrollo asistido por IA, DORA concluye que la IA funciona como un amplificador de las fortalezas y debilidades que ya tiene una organización. Entre las siete capacidades que identifica para aprovecharla están trabajar en lotes pequeños y centrarse en el usuario. Advierte además que, sin ese foco en el usuario, la adopción de IA puede afectar negativamente el desempeño de los equipos: se avanza más rápido, pero en la dirección equivocada [15]. Para un cliente esto tiene una consecuencia práctica: que un proveedor programe más rápido con IA no reduce la necesidad de revisar lo construido con frecuencia. La aumenta.

En cuanto al tamaño de la organización, el 17.º State of Agile Report de Digital.ai (2024) encontró que en las organizaciones pequeñas el 52 % de los encuestados dice que el enfoque ágil funciona bien, frente al 43 % en las grandes [13]. Hay que tener en cuenta que es una encuesta global de un proveedor, no aleatoria, y que allí “pequeña” significa hasta 1.000 empleados, una escala muy distinta a la de una pyme colombiana típica. La edición siguiente, el 18.º informe (octubre de 2025), se concentró en empresas de más de 20.000 empleados, por lo que no ofrece un dato comparable para organizaciones pequeñas; sí reporta que el 74 % de los encuestados usa modelos ágiles híbridos o adaptados [16]. En Colombia, un estudio de la Universidad Santo Tomás con 314 profesionales de desarrollo en Bogotá encontró que Scrum es la metodología más adoptada (43,95 %) y que el 26,75 % reporta subestimar el esfuerzo entre 5 % y 25 % [14]. Estimar bien un proyecto completo desde el inicio es difícil, y revisar cada dos semanas permite corregir la estimación con datos reales.

Lo que este modelo le pide al cliente

Entregar cada dos semanas también tiene costos, y la mayoría recae en el cliente:

• Tiempo fijo. Alguien de la empresa debe reservar tiempo cada dos semanas para revisar lo entregado y decidir qué sigue. El Manifiesto Ágil plantea que las personas de negocio y los desarrolladores trabajen juntos durante todo el proyecto [9], y la Guía de Scrum asigna a un responsable del producto la tarea de ordenar las prioridades [10]. Sin esa persona, la iteración pierde casi todo su valor.
• Alcance ajustable. En lugar de una lista cerrada y prometida, se trabaja con una lista priorizada que cambia según lo que se aprende. Esto debe quedar claro en el contrato, por ejemplo con presupuesto por iteraciones.
• Software incompleto pero funcional. Las primeras entregas hacen pocas cosas, pero las hacen de verdad. No son maquetas.
• Disposición a cambiar. La encuesta de Digital.ai identifica la resistencia al cambio y la falta de entendimiento del enfoque por parte de la dirección como las principales barreras [13].

A cambio, el cliente gana control. En cualquier ciclo puede detener el proyecto, cambiar de prioridad o lanzar lo que ya existe, con software utilizable en la mano. Con el modelo de entrega única, en cambio, el riesgo de descubrir al final que se pagó por algo que nadie usa queda concentrado en el último día.

Fuentes

1. ProjectManagement.com. “The Waterfall Misconception: What Dr. Royce Really Said in 1970”. PMI. Artículo. Referencia original: Royce, W. W. “Managing the Development of Large Software Systems”. Proceedings of IEEE WESCON, 1970.
2. Feitelson, D. (material de curso). “The Waterfall Model” (diapositivas sobre Royce, 1970). The Hebrew University of Jerusalem, 2009. Diapositivas.
3. Cohn, M. “Are 64% of Features Really Rarely or Never Used?”. Mountain Goat Software, actualizado el 13 de noviembre de 2016. Artículo.
4. Patton, J. User Story Mapping. O’Reilly Media, 2014 (cita reproducida en Goodreads). Referencia.
5. Pendo. The 2019 Feature Adoption Report. Pendo.io, 2019. Informe.
6. Kohavi, R. “Online Controlled Experiments: Introduction, Learnings, and Humbling Statistics” (charla en ACM RecSys). 2012. Presentación.
7. Eveleens, J. L. y Verhoef, C. “The Rise and Fall of the Chaos Report Figures”. IEEE Software, 27(1), 30–36, 2010. DOI 10.1109/MS.2009.154. IEEE Xplore.
8. Morris, D. J. C. “Waterfall More Successful Than Agile?” (sobre el CHAOS Manifesto 2013 del Standish Group). 27 de enero de 2015. Artículo.
9. Beck, K. et al. Principios detrás del Manifiesto Ágil. 2001. Manifiesto Ágil.
10. Schwaber, K. y Sutherland, J. La Guía de Scrum. Scrum.org / ScrumInc., noviembre de 2020. Guía.
11. DORA. “Capabilities: Working in small batches”. Google Cloud. DORA.
12. DORA. “DORA’s software delivery metrics: the four keys”. Google Cloud. DORA.
13. Digital.ai. “17th State of Agile Report: 71% Use Agile in their SDLC” (comunicado). Business Wire, 16 de enero de 2024. Business Wire. Ver también: SD Times, “Report: Small businesses are seeing greatest benefits from Agile”, 2024. SD Times.
14. Prieto Bustamante, F. Estudio sobre estimación de esfuerzo en proyectos de desarrollo ágil en Bogotá. Universidad Santo Tomás, 2025. Repositorio USTA.
15. DORA. State of AI-assisted Software Development 2025. Google Cloud, 2025. Informe DORA y Google Cloud, “Introducing DORA’s inaugural AI Capabilities Model”, 23 de septiembre de 2025. Google Cloud.
16. Digital.ai. “Digital.ai’s 18th State of Agile Report Marks the Start of the Fourth Wave of Software Delivery” (comunicado). Business Wire, 28 de octubre de 2025. Business Wire.