Es hora de poner fin a la discusión: ¿eres ágil realmente?

Este artículo tiene como objetivo terminar de una vez por todas con la confusión y las preguntas que existen con respecto a la agilidad. Así que comencemos con lo más básico, el significado de “ágil”.

¿Qué significa la palabra ágil?

Comenzamos con la siguiente afirmación de mi propia autoría:

“Ser ágil es una cualidad, un objetivo que se trata de alcanzar”.

¿Entendido? Pues, posiblemente una parte de la mente lo entiende pero no es tan fácil aterrizar la frase. De repente, la definición se vuelve muy abstracta por lo que la respuesta más honesta que esperaría sería: ‘¡NO!’ o ‘No del todo.’ 

Así que mejor dividir la frase para una comprensión más real. Si buscamos en diccionarios qué significa una cualidad, vamos a encontrar respuestas como las siguientes: 

• Un rasgo permanente y distintivo de la esencia de una persona o cosa. / Una característica o rasgo de una persona u objeto.

Ok, vemos que una cualidad es una característica o rasgo, algo que nos distingue. Pero no nos detengamos ahí. Si buscamos qué significa ser ágil (sin contextos de gestión de proyectos aún) encontramos respuestas como: 

• La capacidad de reaccionar rápidamente con movimientos adecuados ante situaciones cambiantes. 

Muy bien, entonces podemos comenzar a ampliar la primera frase y decir que: ser ágil es tener la característica permanente de poder reaccionar rápidamente ante situaciones cambiantes. Y es un objetivo dado que no siempre se cuenta con esa capacidad, es un trabajo constante que se debe ir mejorando con el tiempo.

Entendido. Pero, ¿cuando se trata de gestión de proyectos?

Realmente es la misma esencia que acabamos de definir, el tener la capacidad de reaccionar de forma correcta ante los cambios. En desarrollo ágil, asumimos que habrá incertidumbre y la misma se supera a través de iteraciones, anticipación y adaptación. Pero tener esta capacidad requiere una forma de pensamiento y trabajo que se debe aplicar para obtener mejores resultados. Aquí, por lo tanto, es importante explicarlo desde su fundación. 

La metodología ágil nace de una forma “oficial” o “popular” en Febrero del 2001, cuando 17 exponentes de la informática y administración (luego conocidos como el Agile Alliance) se reunieron en Snowbird, Utah (un resort de Ski) con la intención de buscar una forma de desarrollar proyectos basada más en la confianza, respeto y colaboración. Como resultado, se obtuvo la creación del simbólico “Manifiesto para Desarrollo de Software Ágil“.  En este manifiesto, se definieron los 4 pilares del desarrollo ágil así como 12 principios que salen de estos pilares (https://agilemanifesto.org/). No vamos a entrar a detallar los 12 principios pero si se utilizarán junto con los pilares para dar fuerza a nuestra explicación. Los 4 pilares o aspectos son:

Individuos e interacciones sobre procesos y herramientas.

Software funcionando sobre documentación extensiva.

Colaboración con el cliente sobre negociación contractual.

Respuesta ante el cambio sobre seguir un plan.

Estas son literalmente las bases; todo el desarrollo ágil se expande de una forma que se sostiene de estos 4 pilares y que se puede agrupar en 3 explicaciones cortas:

Colaboración e interacciones

Uno de los factores más importantes para el éxito de una metodología ágil es el factor humano. Pero no solo los actores como tal, sino que las interacciones que existen entre ellos también. Esto a su vez se puede observar en dos líneas que no pueden fallar:

Primero, la comunicación del equipo de trabajo con los clientes o stakeholders. Esta debe ser continua; si se dejan plazos largos de tiempo donde no se da retroalimentación alguna o si el equipo no busca al cliente en momentos de duda y viceversa, estamos condenando al proyecto.

Segundo, la sinergia del equipo como tal, el poder crear equipos auto organizados así como motivados. Esto significa confiar en que el grupo de trabajo tiene las capacidades suficientes para realizar la tarea asignada al poseer características tales como: saber maximizar el trabajo que realizan y no caer en retrabajos, el poder crear las arquitecturas de las soluciones de forma correcta con una visión clara de los requerimientos y, finalmente, ser un equipo de alto rendimiento que siempre busca la mejora continua. 

Lo anterior se puede mapear con los principios: 4, 5, 6, 9, 10, 11 y 12.

Software funcional e iterativo

La idea fundamental de un desarrollo ágil es el poder entregar valor desde momentos tempranos de un proyecto (factor diferenciador de un desarrollo tradicional). Esto viene de la mano con el concepto de entregas continuas. Tal cual se explica en el punto anterior, debe existir un canal de comunicación y retroalimentación continuo con el cliente, pero ¿cómo logramos esa retroalimentación? Pues la respuesta es con valor real, con software (en nuestro caso) que puedan utilizar. Aquí es importante aclarar que las personas confunden este principio y creen que en cada iteración debe salir un entregable para el cliente, más que todo ya cuando aplican un marco de desarrollo (Scrum, XP, etc.) y esto no necesariamente es correcto. 

Dar valor es tener claro cuándo vamos a entregar, no simplemente entregar lo que se lleva. Esto puede provocar efectos negativos cuando los clientes reciben muchas entregas pero estas vienen siendo “lo mismo” porque el trabajo que implican puede que no sea visible y dejan de darle importancia al proceso. Recordemos esto: ¡se debe entregar cuando hay valor para el cliente! 

Y bueno, es iterativo e incremental porque efectivamente vamos a ir realizando mejoras en cada ciclo y necesitamos el valioso feedback por parte de los stakeholders. Este punto es, nuevamente, una de las fortalezas del desarrollo ágil por encima de otras metodologías. Esta fortaleza se hace más clara con el siguiente punto.

Lo anterior se puede mapear con los principios: 1,3, 7 y 8.

Responder al cambio

¿Cuál era uno de los mayores problemas de las metodologías tradicionales? Se pasaba un tiempo considerable haciendo un análisis del sistema, se creaban documentos pesados de todos los requerimientos y estos se entregaban a un equipo que, en su propio mundo, desarrollaba todo lo que venía en esos documentos con una línea de tiempo bastante estática. ¿Pero funcionaba? En gran mayoría, no. 

No siempre existe la capacidad de saber todo lo que se va a necesitar al detalle, mucho menos desde el inicio. Esto limitaba mucho al cliente y este terminaba creando requerimientos sin profundidad, lo que al final resultaba en un sistema que no era real en su utilización. Agile viene a decir: ‘cambio, te aceptamos. Eres real y no podemos vivir sin tí’. Con la metodología ágil es importante saber cuál es la finalidad del proyecto pero no es necesario tener la profundidad completa de las funcionalidades del software. 

Cada iteración, cada incremento, cada retroalimentación da la oportunidad para reformular. Suena agotador, pero el beneficio real es esa oportunidad de identificar un cambio de forma temprana (cuando hablamos de proyectos de software, entre antes se identifique, mejor). Esto igual aplica a la detección de riesgos y oportunidades; es muy probable que se detecte un riesgo durante las iteraciones en vez de al inicio, cuando el panorama es muy grande. Aquí vamos a utilizar algo conocido como el “Cono de la Incertidumbre”, el cual se presenta de la siguiente forma:

Éste nos dice que al inicio de un proyecto, la variabilidad o la incertidumbre puede ser muy alta. Conforme se va definiendo el proyecto en detalle, esa variabilidad va a ir disminuyendo y por lo tanto, una estimación inicial puede fallar (bastante). Inclusive aun ya teniendo todos los requerimientos con su diseño detallado, sigue existiendo un mínimo de variabilidad en los proyectos (otro tema interesante relacionado a esto es el ROM: ‘Rough Order of Magnitude Estimate’). Agile ve esto y dice: ¡bienvenido!

Lo anterior se puede mapear con el principio 2, pero incluye indirectamente todos los demás: se necesita un equipo que sepa gestionar cada cambio, que pueda comunicar cada riesgo o cambio de forma cristalina con el cliente y que entregue valor continuamente para ir disminuyendo esa variabilidad.

Dejemos las cosas clara

Vamos a aclarar ciertos puntos para así poner fin a muchas discusiones: 

• La agilidad es entregar VALOR de forma pronta y constante. 
• La agilidad no dice CÓMO hacer las cosas, nos dice QUÉ es lo que debe hacerse para que funcione. Es una filosofía, una forma de pensar y cobija varios marcos de trabajo.
• Los marcos de trabajo como SCRUM, XP, Kanban toman ese QUÉ y dicen: ‘muy bien, lo hacemos así’ (EL CÓMO). 
• Individuos e interacciones sobre procesos y herramientas no quiere decir que no existan herramientas o procesos. Estos siguen siendo definidos y necesarios. Inclusive SCRUM, por ejemplo, cuenta con 19 procesos. Se puede contar con las mejores herramientas y procesos, pero si las interacciones no funcionan o los individuos no conectan, de nada te sirve lo demás. 
• Software funcionando sobre documentación extensiva. De nuevo, siempre va a existir documentación; por ejemplo, los requerimientos deben estar bien detallados para que no existan confusiones. Pero si recordamos, la agilidad valora el valor y muchos documentos realmente no nos dan valor. Se debe tener claro eso en todo momento.
• Colaboración con el cliente sobre negociación contractual. Un contrato es imprescindible y debe ser sumamente claro. Pero este pilar nos habla también de que es mejor hablar y colaborar con el cliente que terminar buscando cláusulas contractuales.
• Respuesta ante el cambio sobre seguir un plan no quiere decir que no debe existir un plan inicial. Todo proyecto debe tener un plan, aunque sea a un nivel aproximado, el cual se debe ir refinando. Pero es más importante tener claro que los cambios van a suceder y se deben manejar. 
• La agilidad no significa aceptar TODOS los cambios que se proponen. Para esto se debe hacer una gestión acorde de cambios y comprender siempre el VALOR que le pueden aportar al proyecto. 
• Una iteración no es lo mismo a una liberación. Para esto se pueden utilizar herramientas como un calendario de ‘releases’ y realizar entregas sólo cuando exista valor real hacia el cliente.  

¿Qué es ser ágil?

Bueno, ya con toda esta explicación podemos quedarnos con una definición más completa y corta:

“Ser ágil es la capacidad de crear y responder al cambio de una forma que siempre genere VALOR en un proyecto.”

• Buena comunicación interna y externa.
• Entregar valor de forma continua y temprana.
  Un equipo auto gestionado.
• Entender que el cambio es algo que puede suceder y para lograr el éxito, es necesario aceptarlo.