A principios de 2001, con la cordillera Wasatch como telón de fondo, en Snowbird (Utah), 17 personas se reunieron para debatir el futuro del desarrollo de software. Los miembros del grupo compartían la frustración sobre el estado actual de los acontecimientos, aunque no estaban de acuerdo en la forma de remediar la situación.

El problema, coincidieron, era que las empresas estaban tan centradas en planificar y documentar hasta el último detalle de los ciclos de desarrollo de software, que habían perdido de vista lo realmente importante: complacer a los clientes.

Las empresas podían haber pregonado valores corporativos como la “excelencia” y la “integridad”, pero estos valores no habían servido para guiar a las personas, sobre todo a los desarrolladores de software, hacia un camino mejor. Eso tenía que cambiar. Muchos de los 17 que se reunieron en Snowbird ya tenían ideas sobre cómo iniciar la nueva era del desarrollo de software.

Este viaje a las montañas fue su oportunidad para debatirlas.

El manifiesto ágil surgió de este largo fin de semana con solo 68 palabras, pero este breve y bendito documento cambió el desarrollo de software para siempre. En las casi dos décadas que han pasado desde que se creó, un sinfín de personas, equipos y empresas han adoptado (en diversos grados) estas palabras (y los 12 principios que las siguen).

El panorama actual está repleto de metodologías que prometen tomar los ideales ágiles y convertirlos en elementos tangibles del mundo real; pero la locura metodológica actual no es nada nuevo.

El propio manifiesto nació de la necesidad de encontrar un terreno común entre el scrum, la programación extrema, la metodología Crystal Clear y otros marcos.

“Estaban empezando a ver que había algo común en lo que estaban haciendo, pero, en ese momento, había mucha competencia, al menos en pensamiento”, dijo Ian Buchanan, ingeniero principal de soluciones para DevOps en Atlassian. “Cuando pones eso en contexto, el hecho de que pudieran ponerse de acuerdo en algo es bastante impresionante”.

Las 17 personas que se reunieron en Snowbird querían ver si los representantes de las diversas disciplinas se podían poner de acuerdo en algo, cualquier cosa, y, sorprendentemente, así fue. Estuvieron de acuerdo en un conjunto de valores que definían una cultura.

Son los siguientes:

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros.

A través de este trabajo hemos aprendido a valorar:

Dar más prioridad a las personas y las interacciones que a los procesos y las herramientas

Dar más prioridad al funcionamiento del software que a la documentación extensiva

Dar más prioridad a la colaboración con el cliente que a la negociación de contratos

Dar más prioridad a la respuesta a los cambios que al seguimiento de un plan

Esto esr, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Los doce principios del software ágil, también resultado de la cumbre de Snowbird, amplían el conjunto de frases que conforman los valores.

Eso es todo. Desde entonces, el sitio del manifiesto ágil apenas ha cambiado, si es que lo ha hecho; pero el mundo que rodea a la metodología ágil no podría ser más distinto.

Los 17 que se reunieron en Snowbird lograron unificar los distintos puntos de vista bajo unos pocos principios básicos, pero el debate no terminó ahí. En cierto modo, la metodología ágil se ha dividido en muchas más formas de trabajar de las que los visionarios debatieron en primer lugar. Parece que todo el mundo tiene su opinión sobre el tema.

En la actualidad, nos encontramos con SAFe, LeSS y otras formas de metodología ágil que no tienen nada que ver con el desarrollo de software, aunque el Manifiesto comience diciendo: "Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros".

Dave West, director general de Scrum.org, que viaja a varias organizaciones para observar las prácticas ágiles, nombró a un equipo de investigación que está usando la metodología ágil para desarrollar una cura para la ceguera genética con virus.

En efecto, se ha impuesto la adopción de la metodología ágil fuera del ámbito del software, pero no es necesariamente lo que pretendían los creadores del manifiesto.

"No es que no se pueda interpretar, pero se requiere un conocimiento más profundo para asegurarse de que las ideas se traduzcan con fidelidad", afirma Buchanan.No siempre se cuenta con dicho conocimiento, incluso dentro del desarrollo de software.

Muchos sostienen que la “metodología ágil falsa”, como también se la denomina, y su hermana gemela malvada, la “metodología ágil oscura”, se ven exacerbadas por la monetización de la educación y la consultoría ágiles. Algunos incluso llegan a llamar a las organizaciones que se encuentran detrás de esta monetización “El complejo industrial ágil”.

“Hay una metodología ágil de culto cargo en la que haces y dices lo correcto, pero no entiendes los principios fundamentales. No vas a obtener los resultados esperados”, afirma Buchanan.

Muchos consideran que Atlassian tiene la culpa de todo esto, ya que nuestras herramientas facilitan marcos ágiles como el de scrum y el de kanban. No obstante, consideramos que la metodología ágil tiene un valor cultural y que los equipos deben estar capacitados para trabajar como mejor les parezca. Los marcos ágiles van de la mano de los valores culturales, pero, si no se cuenta con el estándar cultural, lo que haces podría dar un resultado equivocado desde el principio.

Llamadas "falsas", "oscuras" o "culto cargo", estas subversiones de la metodología ágil suelen conducir a situaciones que van en contra de las intenciones del manifiesto (la microgestión, el ritmo de desgaste, la falta de entrega y el cumplimiento del proceso sobre los principios se registran como las más atroces), incluso si los que las practican vienen con un certificado bajo el brazo. Por desgracia, estas experiencias oscuras con la metodología ágil hacen que algunas personas renieguen de ella (o que la reescriban para reflejar su experiencia en el mundo real con ella).

Ron Jeffries, uno de los 17 en la Snowbird, ha intentado abordar estas aberraciones con esta calificación: "En este y en otros escritos, utilizo la palabra citada 'ágil' para referirme a las muchas instancias, enfoques y procesos que utilizan el término 'ágil' para describirse a sí mismos, pero que no necesariamente siguen el documento o el espíritu del desarrollo de software ágil sobre el que escribimos en el Manifiesto ágil. A veces usaré el término de 'metodología ágil falsa', para hacer hincapié, o el de 'metodología ágil oscura', que uso para describir los llamados enfoques 'ágiles' que realmente han salido mal. Por otra parte, usaré 'Manifiesto ágil' para referirme a las ideas principales del Manifiesto, en las que todavía creo".

No obstante, dada la amplia, y a veces equivocada, adopción del concepto “metodología ágil”, ¿sigue siendo el manifiesto ágil un documento de referencia?

Después de hablar con cientos de clientes de Atlassian, orientadores ágiles internos y externos, y profesionales entusiastas y ávidos, por no mencionar la ingente cantidad de tiempo que hemos pasado leyendo sobre ello en las redes sociales, puedo decir con total seguridad que la respuesta es "sí".El Manifiesto sigue siendo relevante, tal vez incluso más ahora que nunca.

Mis compañeros Dan Radigan, orientador ágil sénior para empresas, e Ian Buchanan, que trabajan con clientes todos los días, confirmaron que hacen hincapié en el manifiesto con nuevos clientes de forma regular. 

Tanner Wortham, orientador ágil y gestor sénior del programa técnico de LinkedIn, dice que también lo cita a menudo.Wortham, que pasó 10 años en los Marines, afirma que empezó a poner en práctica la metodología ágil incluso antes de saber que tenía nombre. Para él, solo se llamaba “dirigir a los Marines” y considera que poner nombre a algo constituye un gran primer paso para abordarlo.

“En realidad uno no sabe qué hacer con algo que no tiene nombre. Creo que eso es lo que se hizo en el manifiesto: pensaron en un nombre y lo acabaron llamando ‘metodología ágil‘. Pienso que era algo que ya estaba ocurriendo, pero, cuando le pusieron nombre, pudieron empezar a identificarlo con más facilidad”.

West, director general de Scrum.org, señala que los principios ágiles no son ninguna novedad. Simplemente se aplican de una manera distinta.

“Cuando me paro a pensar en los principios que hay detrás del manifiesto, me doy cuenta de que no son principios que hayamos inventado nosotros”, dijo West. “Son los principios del método científico: Galileo los usó y Arquímedes también”.

Tal vez el mayor logro del manifiesto ágil sea que haya codificado una forma de pensar que aún no se había utilizado para el desarrollo de software, lo que, desde luego, no es poco.

Los principios ágiles existían antes del manifiesto ágil. La gente los aplicaba al desarrollo de software y se recogieron en el manifiesto. A continuación, la gente tomó los principios del manifiesto y comenzó a aplicarlos a su propio trabajo. Con todo el reciclado de ideas, ¿ha llegado la hora de actualizar el manifiesto ágil?

No necesariamente.

Cuando algo tan importante a nivel cultural como el manifiesto aparece, se puede reinterpretar, pero no hay nada como el original. Así que, en lugar de intentar actualizarlo oficialmente, quizás sea mejor averiguar cómo aplicarlo a ti mismo, a tu equipo o a tu organización.

“En muchos sentidos, el manifiesto es la base de una conversación”, dijo Wortham. “Así es como lo interpreto yo. ¿Cómo lo interpretas tú? Vale, pues vamos a ver cómo podemos trabajar juntos”.

En ese sentido, tal vez lo importante no sea un bendito documento con el que todos puedan estar de acuerdo, sino el hecho de que un grupo de personas (desde un equipo hasta una organización entera) pueda o no aplicar las ideas del manifiesto a su situación concreta sin perder de vista su espíritu. Y si podemos hacerlo bien, las posibilidades son ilimitadas.

“Creo que si lo hacemos bien, el mundo puede ser maravilloso: podremos curar el cáncer y mis hijos probablemente vivirán hasta los 150 o 175 años”, afirma West. “Pienso que podemos hacerlo y que lo conseguiremos”.

Un agradecimiento especial a Amanda O'Callaghan, Ian Buchanan, Dan Radigan, David West y Tanner Wortham por compartir sus conocimientos y experiencia para este artículo.