← volver

"Cuando lo ágil no es tan ágil"

Alejandro Barros

 

Desde hace un tiempo a esta parte, he visto como muchas iniciativas de modernización en la región que tienen una componente significativa de soporte tecnológico, han al menos en su discurso adoptado metodologías ágiles para su desarrollo. Podríamos decir:  lo ágil esta de moda!

Si bien alabo las ventajas de este tipo de metodologías en sus distintos sabores, creo que hay bastante confusión y poca claridad a la hora de adoptarlas, y me da más impresión de que se comete uno de los entusiasmos peligrosos en el ámbito de los proyectos tecnológicos, identificados por Robin Gauld y Shaun Goldfinch en su libro Dangerous Enthusiasms, hay varios elementos que le son propios de las metodologías ágiles, que no se asumen como esenciales para su éxito:

• Cascada desordenado versus ágil, muchas veces llama la atención con el gusto por la utilización de este tipo de métodos, quedando la impresión que su adopción se hace más por “evitarse la documentación” que por aumentar la generación valor y reducir los tiempos y esfuerzos del proceso de desarrollo.

• No identificar el esfuerzo por parte de las áreas funcionales (product owners), no se visualiza que la dedicación en una metodología de desarrollo ágil es muy demandante a todo lo largo del proyecto.  Esto es consustancial a este tipo de desarrollo, y si bien en los métodos tradicionales la dedicación de tiempo también era necesaria, al no cumplirla se notaba menos.

• No se analizan las potenciales dificultades de gestión del contrato, en general los contratos en el ámbito público tienen lógica de método tradicional, esto se puede ver en como se definen los hitos de pago, y  el proceso de entregables  (diseño, desarrollo, pruebas, puesta en marcha, ….).  Es muy frecuente encontrar proyecto en los que se declara que se quiere usar un método ágil, pero el proyecto se administra contractualmente con lógica cascada.

• Otro error frecuente, es usar métodos de trabajo y herramientas que no tienen incorporado la lógica de proyecto ágil, y su modelo de gestión termina siendo lo que podríamos denominar un jira-mono-canguro

 No todos los proyectos son adecuados para este tipo de metodología, en proyectos de gran tamaño, como son habituales en el Estado, esta metodologías pueden llevar en la dirección incorrecta.

Si a esto le incorporamos los atributos de los proyectos en el Estado, control de organismo externos (contralorías y otros), modalidades de contratación más bien rígidas, presupuestos y modelos de pagos con bastantes restricciones a la hora gestionarlos, es que nos podemos encontrar con más de alguna sorpresa al usar métodos ágiles.

El siguiente cuadro comparativo puede ayudar a entender mejor aquellos elementos que hay que tener en cuenta a la hora de la adopción de una de estas metodologías en el mundo público.

 

Esto se parece mucho a cuando se pide soluciones de alta disponibilidad, pero mi organización no opera en modo 24/7, podríamos hacer el mismo análisis respecto de proyectos en modalidad ágil,  esto es, la pregunta es ¿mi organización (personal, practicas, métodos) son ágiles?

Imagen: http://www.obs-edu.com/blog-project-management/agile-project-management-2/pasate-la-metodologia-agil/

Alejandro Barros
“El Escritorio de Alejandro Barros”, 26 de septiembre de 2015