Español

Manifiesto Agile: Los 4 Valores y 12 Principios Explicados

Resumen de los 4 valores y 12 principios del Manifiesto Agile

El Manifiesto Agile es uno de los documentos más leídos en la historia del software, y solo tiene 68 palabras. Diecisiete profesionales lo redactaron en febrero de 2001 en un resort de esquí en Snowbird, Utah, frustrados por años de procesos excesivamente complejos que producían software tardío que nadie quería.

Pero la influencia del documento fue mucho más allá del software. Hoy, los equipos de marketing ejecutan Sprints. Los departamentos de RRHH realizan retrospectivas. Los equipos de operaciones usan tableros Kanban. Los cuatro valores y doce principios del Manifiesto Agile son la base de todo ello.

Esta guía desglosa exactamente qué dicen esos valores y principios, qué significan en la práctica y cómo puede aplicarlos en cualquier equipo.

¿Qué es el Manifiesto Agile?

El Manifiesto Agile es un breve documento fundacional escrito en febrero de 2001 por 17 profesionales del software en el resort de esquí Snowbird en Utah. Define cuatro valores centrales y doce principios que priorizan a las personas, los resultados funcionales y la adaptabilidad por encima de los procesos rígidos y la planificación exhaustiva inicial.

Los 17 firmantes incluyeron a algunas de las figuras más influyentes de la ingeniería de software: Kent Beck (creador de Extreme Programming), Jeff Sutherland y Ken Schwaber (co-creadores de Scrum), Martin Fowler, Jim Highsmith, Alistair Cockburn y otros once. Su frustración era compartida: los procesos pesados orientados al plan producían constantemente software tardío, con sobrecostos y ya obsoleto para el día del lanzamiento.

El documento está publicado en agilemanifesto.org y nunca ha sido revisado. Permanece exactamente como fue escrito en 2001.

Datos clave

  • El Manifiesto Agile fue publicado en febrero de 2001 en agilemanifesto.org, firmado por 17 profesionales del software. Sus cuatro valores suman 68 palabras, sin cambios desde su publicación.
  • El 18th Annual State of Agile Report (Digital.ai, 2024) encontró que el 71% de las organizaciones utilizan enfoques Agile, frente al 37% en 2011.
  • Un análisis del Standish Group CHAOS Report encontró que los proyectos Agile tienen tasas de éxito significativamente más altas que los de Waterfall: 42% de tasa de éxito frente al 13% de Waterfall al controlar el tamaño del proyecto (edición 2020).

Comprender el Manifiesto es también contexto esencial para la metodología Agile en su conjunto, ya que todos los marcos principales (Scrum, Kanban, XP) trazan su linaje hasta este documento.

Los 4 Valores del Manifiesto Agile

Los cuatro valores del Manifiesto Agile

El Manifiesto lo afirma claramente: "Estamos descubriendo mejores maneras de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos aprendido a valorar..."

Luego lista cuatro pares de valores. Cada uno está escrito como "X sobre Y." La aclaración que sigue es igualmente importante: "Aunque valoramos los elementos de la derecha, valoramos más los de la izquierda."

Ese matiz importa. El Manifiesto no dice que los contratos no tengan valor. Dice que la colaboración con el cliente importa más. No dice que la documentación sea inútil. Dice que el software funcional tiene prioridad.

Valor Lo que favorece Lo que no rechaza
Individuos e interacciones sobre procesos y herramientas Comunicación directa, juicio humano, relaciones de equipo Procesos y herramientas (simplemente no son lo principal)
Software funcionando sobre documentación exhaustiva Entregar algo funcional con lo que los usuarios puedan interactuar Documentación (siga escribiéndola, pero no deje que reemplace la entrega)
Colaboración con el cliente sobre negociación contractual Diálogo continuo con las personas que usan el producto Contratos (son necesarios, pero no son la meta principal)
Respuesta ante el cambio sobre seguir un plan Ajustarse según lo aprendido durante la entrega Planes (empiece con uno, pero no lo siga ciegamente)

Valor 1: Individuos e Interacciones sobre Procesos y Herramientas

Una reunión de Standup donde las personas realmente identifican los bloqueos vale más que una herramienta de seguimiento de proyectos perfectamente mantenida que nadie lee. Este valor es un recordatorio de que el proceso es un medio, no un fin.

En la práctica: si su equipo dedica más tiempo a actualizar el sistema que a hablar sobre el trabajo real, algo está al revés.

Valor 2: Software Funcionando sobre Documentación Exhaustiva

Este es el valor más malinterpretado. Los equipos a veces lo leen como "no escriba documentación." No es lo que dice. Afirma que un producto funcional en manos de un usuario genera más aprendizaje que un documento de especificaciones. Un prototipo que se entrega en la semana dos le dice más que un documento de requisitos de 40 páginas escrito en el mes uno.

Valor 3: Colaboración con el Cliente sobre Negociación Contractual

Los contratos definen lo acordado al inicio. Los clientes saben lo que realmente necesitan después de ver las primeras iteraciones. La colaboración regular, las demos y los ciclos de retroalimentación permiten que el producto evolucione hacia lo que el cliente realmente quiere, no solo lo que anotó en el brief original.

Valor 4: Respuesta ante el Cambio sobre Seguir un Plan

Los mercados cambian. Los competidores lanzan productos. La retroalimentación de los usuarios sorprende. Un plan escrito antes de que comenzara el trabajo refleja supuestos, no realidad. Los equipos Agile actualizan su plan a medida que aprenden. La planificación del Sprint es donde este valor se operacionaliza: los equipos planifican un Sprint a la vez, no seis meses de una sola vez.

Los 12 Principios de Agile

Los 12 principios de Agile

Los doce principios desarrollan cada valor en orientación accionable. Fueron escritos junto a los cuatro valores y están publicados como página complementaria en agilemanifesto.org/principles.html.

# Principio Significado en lenguaje simple
1 Satisfacer al cliente mediante la entrega temprana y continua de software valioso. Entregue algo útil desde el principio. No espere hasta que todo sea perfecto.
2 Bienvenidos los requisitos cambiantes, incluso al final del desarrollo. El cambio tardío no es un fracaso. Es información. Construya procesos que puedan absorberlo.
3 Entregue software funcionando con frecuencia, desde un par de semanas hasta un par de meses, con preferencia por la escala de tiempo más corta. Los ciclos cortos superan a los largos. Cuanto más frecuentemente entregue, más rápido aprende.
4 Los responsables del negocio y los desarrolladores deben trabajar juntos a diario durante todo el proyecto. Las personas que entienden el dominio y las que construyen el producto no deben operar en silos.
5 Construya proyectos en torno a individuos motivados. Déles el entorno y el apoyo que necesitan, y confíe en ellos para que hagan el trabajo. La autonomía y la confianza producen mejores resultados que la vigilancia y la microgestión.
6 El método más eficiente y efectivo de comunicar información a un equipo de desarrollo es la conversación cara a cara. La conversación directa supera las cadenas de documentación. (Las videollamadas cuentan.)
7 El software funcionando es la medida principal del progreso. Los puntos de Velocity, los tickets cerrados y las funcionalidades iniciadas son indicadores indirectos. La única medida real es algo que funcione.
8 Los procesos Agile promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante indefinidamente. El trabajo intensivo no es una estrategia. Los equipos que corren a máxima velocidad durante meses se agotan y producen trabajo con errores.
9 La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. El código deficiente lo hace más lento con el tiempo. Tomar atajos para ir más rápido ahora lo hace más lento después.
10 La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial. Haga menos. La mejor funcionalidad es la que no tiene que construir. El mejor paso del proceso es el que puede eliminar.
11 Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados. Los mandatos de arriba hacia abajo producen cumplimiento. Los equipos auto-organizados producen pertenencia y creatividad.
12 A intervalos regulares, el equipo reflexiona sobre cómo volverse más efectivo, y ajusta su comportamiento en consecuencia. Las retrospectivas de Sprint no son opcionales. La mejora continua está integrada en el ritmo de trabajo.

Tres principios son los más importantes para equipos fuera del software: el Principio 2 (bienvenida el cambio tardío), el Principio 10 (maximice el trabajo no realizado) y el Principio 12 (retrospectivas regulares). Estos se aplican igualmente a campañas de marketing, procesos de RRHH y flujos de trabajo de operaciones.

Por qué el Manifiesto Agile Sigue Siendo Relevante

El Manifiesto fue escrito en reacción a un problema específico: proyectos de software que fallaban porque intentaban predecir y especificar todo por adelantado. Ese problema no ha desaparecido. Si acaso, ha empeorado.

Estas son las razones por las que la relevancia del Manifiesto ha crecido:

El trabajo es más complejo. Los problemas que los equipos abordan en 2026 (integración de IA, trabajo distribuido, lanzamientos en múltiples mercados) son más difíciles de especificar por adelantado que los proyectos de software empresarial de 2001. La entrega iterativa y los ciclos de aprendizaje rápido son aún más importantes.

Los ciclos de retroalimentación son más rápidos y económicos. En 2001, lanzar algo implicaba versiones físicas o despliegues nocturnos. Ahora, un equipo puede lanzar una funcionalidad al 10% de los usuarios en minutos y medir resultados en horas. La apuesta del Manifiesto por la retroalimentación rápida es aún más recompensada.

Agile ha ido más allá del software. Los equipos de marketing, RRHH, finanzas y operaciones ejecutan Sprints. Los 12 principios son independientes del dominio. El Principio 8 (ritmo sostenible) se aplica a cualquier equipo. El Principio 10 (maximizar el trabajo no realizado) se aplica a cualquier proceso. El Principio 12 (retrospectivas regulares) se aplica a cualquier grupo que intente mejorar.

La decisión entre Agile vs Waterfall sigue siendo la elección estratégica más común a la que se enfrentan los equipos al iniciar una nueva iniciativa, y el Manifiesto es la articulación más clara de lo que hace diferente a Agile.

Conceptos Erróneos Comunes sobre Agile

El Manifiesto se malinterpreta constantemente. Estos son los errores más comunes y lo que el documento realmente dice.

Concepto erróneo 1: "Agile significa no planificar."

No lo es. El Manifiesto dice "respuesta ante el cambio sobre seguir un plan", no "nunca planifique." Cada Sprint comienza con una planificación del Sprint. Cada trimestre comienza con la definición de objetivos. La diferencia es que los planes Agile se actualizan a medida que llega nueva información, en lugar de seguirse rígidamente sin importar lo que se aprenda.

Concepto erróneo 2: "Agile significa ninguna documentación."

El Manifiesto valora el software funcionando sobre la documentación exhaustiva. "Exhaustiva" es la palabra clave. Escriba documentación que sea útil. No escriba documentación como sustituto de entregar algo.

Concepto erróneo 3: "Agile es solo para equipos de software."

El Manifiesto fue escrito por profesionales del software, pero los valores no son específicos del software. El Principio 1 (entrega temprana de valor), el Principio 2 (bienvenida el cambio) y el Principio 12 (retrospectivas regulares) se aplican a cualquier equipo que realice trabajo complejo.

Concepto erróneo 4: "Agile significa no tener plazos."

Los equipos Agile tienen plazos. Las revisiones del Sprint ocurren en fechas fijas. Los lanzamientos de productos tienen ventanas de lanzamiento. La diferencia es que los equipos Agile negocian el alcance para cumplir con la fecha, en lugar de negociar la fecha para ajustarse al alcance.

Concepto erróneo 5: "Scrum es Agile."

Scrum es una implementación de los valores Agile. También lo es Kanban. También lo es Extreme Programming. Agile es la filosofía; Scrum es una receta que la sigue. Puede ser Agile sin ejecutar Scrum. Puede ejecutar ceremonias de Scrum sin ser realmente Agile (esto se llama "Agile de cargo cult" y es más común de lo que la mayoría de las organizaciones quieren admitir).

Cómo Aplicar el Manifiesto Agile en su Equipo

No necesita adoptar un marco formal para comenzar a aplicar los valores Agile. Aquí se muestra cómo pasar de los principios del Manifiesto a la práctica real.

Paso 1: Identifique su "desperdicio" actual

Observe dónde su equipo dedica tiempo a cosas que no producen valor directamente. Largas cadenas de aprobación, informes de estado que nadie lee, reuniones que podrían ser un mensaje. El Principio 10 (maximizar el trabajo no realizado) comienza aquí.

Paso 2: Acorte su ciclo de entrega

¿Cuál es la cosa más pequeña que su equipo podría entregar a la que un usuario real pudiera reaccionar? Si su ciclo actual es trimestral, apunte a mensual. Si es mensual, apunte a quincenal. Los gráficos Burndown pueden ayudarle a visualizar si el trabajo que se entrega cada ciclo realmente se está completando.

Paso 3: Incluya al cliente antes en el proceso

Su "cliente" puede ser un cliente externo, un stakeholder interno o un usuario final. Quien sea, encuentre una manera de mostrarle el trabajo en progreso en lugar del trabajo terminado. La retroalimentación temprana es económica. La retroalimentación tardía es costosa.

Paso 4: Comience un hábito de retrospectivas

Reserve 30-60 minutos al final de cada ciclo de trabajo para hacer tres preguntas: ¿Qué salió bien? ¿Qué no salió bien? ¿Qué cambiaremos? El Principio 12 es el retorno compuesto de Agile. Los equipos que realizan retrospectivas constantemente mejoran más rápido que los que no. La versión formal es una retrospectiva de Sprint, pero incluso un documento compartido simple puede servirle de punto de partida.

Paso 5: Experimente con límites de trabajo en progreso

Elija una etapa de su flujo de trabajo (En Progreso, En Revisión o similar) y limite cuántos elementos pueden estar en ella a la vez. Tanto Scrum como Kanban coinciden en una cosa: terminar el trabajo en progreso supera al hecho de comenzar trabajo nuevo. Los límites de trabajo en progreso imponen ese comportamiento.

Paso 6: Dé más autonomía a su equipo

El Principio 11 dice que los mejores resultados provienen de equipos auto-organizados. Eso significa que las personas que hacen el trabajo deben tener voz en cómo se hace. Empiece con algo pequeño: permita que el equipo decida cómo ejecutar sus Standups, o permita que estimen su propia capacidad en cada Sprint en lugar de que un gerente establezca los objetivos.

Ejemplos del Manifiesto Agile por Rol y Función

Los cuatro valores se ven diferentes dependiendo de quién hace el trabajo.

Función Valor en acción Ejemplo práctico
Ingeniería Software funcionando sobre documentación Entregue un prototipo funcional a usuarios beta en la semana 2, en lugar de escribir una especificación de 30 páginas para un ciclo de revisión de un mes.
Marketing Respuesta ante el cambio sobre seguir un plan Lance una campaña en Sprints de dos semanas. Si el primer conjunto de anuncios tiene bajo rendimiento, ajuste el mensaje antes de gastar todo el presupuesto.
Producto Colaboración con el cliente sobre negociación contractual Realice entrevistas de usuario cada dos semanas durante el desarrollo, en lugar de una sola ronda de recopilación de requisitos al inicio.
RRHH / People Ops Individuos e interacciones sobre procesos y herramientas Use conversaciones 1:1 y retroalimentación directa para detectar problemas de desempeño temprano, en lugar de depender únicamente del sistema de revisión anual.
Operaciones Respuesta ante el cambio sobre seguir un plan Mantenga un tablero de priorización MoSCoW para las solicitudes entrantes, de modo que los problemas urgentes se resuelvan sin descarrilar el trabajo planificado.
Diseño Colaboración con el cliente sobre negociación contractual Comparta wireframes de baja fidelidad con los usuarios finales en cada Sprint. Use sus reacciones para revisar antes de comprometerse con una construcción completa.

Las historias de usuario son una de las herramientas más prácticas para cerrar la brecha entre las necesidades del cliente y los elementos de trabajo del equipo. Son el artefacto Agile que hace tangible el Valor 3 (colaboración con el cliente).

Preguntas Frecuentes

¿Quién escribió el Manifiesto Agile?

El Manifiesto Agile fue escrito por 17 profesionales del software que se reunieron en el resort de esquí Snowbird en Utah en febrero de 2001. El grupo incluyó a Kent Beck, Jeff Sutherland, Ken Schwaber, Martin Fowler, Jim Highsmith, Alistair Cockburn, Ward Cunningham y otros nueve. Firmaron el documento colectivamente como autores, aunque el término "Agile" fue propuesto durante la propia reunión.

¿Cuándo fue publicado el Manifiesto Agile?

El Manifiesto Agile fue publicado en febrero de 2001, específicamente del 11 al 13 de febrero de 2001, durante un retiro de tres días en el resort Snowbird en Utah. El documento fue publicado en línea en agilemanifesto.org y no ha sido revisado desde entonces.

¿Cuáles son los 4 valores del Manifiesto Agile?

Los cuatro valores son: (1) Individuos e interacciones sobre procesos y herramientas, (2) Software funcionando sobre documentación exhaustiva, (3) Colaboración con el cliente sobre negociación contractual, y (4) Respuesta ante el cambio sobre seguir un plan. Cada par de valores significa que el lado izquierdo tiene prioridad, pero el lado derecho sigue teniendo valor.

¿Cuál es la diferencia entre los 4 valores y los 12 principios?

Los 4 valores son la base filosófica: indican lo que los equipos Agile priorizan. Los 12 principios son la expansión operativa: explican cómo actuar sobre esos valores en la práctica. Por ejemplo, el Valor 4 dice "responda al cambio." El Principio 2 dice "bienvenidos los requisitos cambiantes, incluso al final del desarrollo." El Principio 3 dice "entregue software funcionando con frecuencia." Ambos apoyan el mismo valor pero a diferentes niveles de especificidad.

¿Sigue siendo relevante el Manifiesto Agile en 2026?

Sí. Los cuatro valores fueron escritos como reacción a los procesos sobre-especificados y orientados al plan. En 2026, esas mismas dinámicas aparecen en el desarrollo asistido por IA, la transformación digital a gran escala y los equipos distribuidos. El Manifiesto no describe herramientas ni tecnologías. Describe prioridades. Y esas prioridades, que favorecen a las personas sobre el proceso, los resultados funcionales sobre la documentación y el aprendizaje sobre la predicción, son tan aplicables hoy como lo eran en 2001. El 18th Annual State of Agile Report (Digital.ai, 2024) encontró que el 71% de las organizaciones ahora reportan usar enfoques Agile.

El Manifiesto Agile no es un artefacto histórico. Es un lente para la toma de decisiones. Cada vez que su equipo se enfrenta a una disyuntiva entre terminar la documentación y lanzar el prototipo, entre seguir el plan original y ajustarse en base a nuevos datos, entre un proceso y una conversación, el Manifiesto le dice hacia qué dirección inclinarse. Esa orientación no caduca.