En la primera parte de este post anterior hablamos de cómo las características particulares de la tecnología software y el tipo de problemas que resuelve fueron abonando el terreno para la aparición de metodologías de desarrollo ligeras e iterativas, en un intento de mejorar las metodologías pesadas y por fases -influidas por las técnicas del desarrollo de proyectos en otros campos- que habían predominado hasta entonces.

En febrero de 2001 diecisiete expertos en desarrollo de software publicaron el “Manifesto for Agile Software Development”, que dio un nombre, una carta de naturaleza y una “marca” a todos esos métodos. Básicamente el Manifiesto consta de cuatro puntos en los que se da prioridad a los individuos y las interacciones, al software que funciona, a la colaboración con el cliente y a la respuesta ante el cambio frente a aspectos como los procesos, la documentación y los planes, que son prioritarios en otros enfoques. Como complemento incluye los doce principios básicos de Agile, entre los que se cuentan la satisfacción del cliente, la entrega temprana y continua de software que funciona, la cooperación y la autoorganización.

Es importante señalar que cuando se habla de Agile se suele hablar en realidad de alguna de las metodologías precursoras que mencionábamos en nuestro post anterior, y en particular de dos que son las más aceptadas (y que son anteriores al Manifiesto):

• Scrum (1995), un marco iterativo e incremental para la gestión de proyectos, inicialmente propuesto para proyectos de desarrollo de productos y cuyo uso se ha centrado en proyectos de desarrollo de software.
• XP (Extreme Programming, 1996) una metodología iterativa de desarrollo de software que aboga por entregas frecuentes de software en ciclos de desarrollo cortos y que recibe ese nombre por su énfasis en llevar al extremo esas buenas prácticas.

En realidad muchos de los principios de Agile (como por ejemplo incrementar la flexibilidad o la comunicación) son ideas de sentido común pensadas para enmendar el mal funcionamiento de las metodologías tradicionales en ciertos escenarios y para arreglar equipos de proyecto disfuncionales. Pero adicionalmente las metodologías Agile incorporan una serie de prácticas, roles y “valores” (daily scrums, war rooms, programación en parejas, retrospectivas, Scrum Masters, Product Owners…) y un énfasis en el funcionamiento del equipo de desarrollo que crean una “liturgia” y contribuyen a fomentar la identificación y la involucración, a veces casi religiosa, de sus practicantes. Lamentablemente, algunas organizaciones encuentran difícil implantar Agile en toda su extensión -con el cambio de cultura que requiere- y se quedan en sus prácticas superficiales, lo que no deja de ser un caso más de “cerdo con lápiz de labios”.

Los beneficios en cuanto a flexibilidad, adaptación, comunicación y coordinación que Agile aporta en escenarios inciertos y volátiles son evidentes. Sin embargo, en estos años se han alzado voces críticas con esta filosofía debido a posibles limitaciones como las siguientes:

• Está muy enfocada en la captura de requisitos y el desarrollo, pero pone un foco escaso en el diseño y en la experiencia global del usuario de la solución
• Falta de estructura y documentación
• Puede aumentar el riesgo de una expansión incontrolada del alcance del proyecto
• Solo funciona bien con desarrolladores experimentados
• Requiere reuniones muy frecuentes con los clientes, con el consiguiente coste
• Dificultad para escalar a proyectos grandes y con personal distribuido geográficamente

Por eso algunos dicen que, si bien Agile tiene cosas buenas y originales, “las cosas buenas no son tan originales y las cosas originales no son tan buenas”… Ese es también el motivo por el que las prácticas de Agile llevan años evolucionando para solucionar sus carencias y ser aplicables en escenarios más generales. En cualquier caso, es evidente que la flexibilidad que aporta Agile no es gratis y a veces sus costes pueden superar a sus beneficios.

Hasta aquí esta introducción a Agile. En próximos posts iremos abriendo el debate sobre preguntas como las siguientes:

• ¿Se puede aplicar Agile más allá del desarrollo de software a medida: proyectos no software, productos software, productos no software?
• ¿Qué beneficios y limitaciones tiene Agile en el desarrollo de productos?
• ¿Cuáles son las relaciones entre Product Manager y Product Owner?
• ¿Cómo implantar un Agile Product Management?

Este post en Marketing & Innovación.