Cuando lo ágil, no es tan ágil
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/
Bueno el artículo, como añadidura hay un factor que pones tangencialmente y es el de competencias. Aún en el sector privado es un conocimiento difícil de encontrar el de aquel que guía las sesiones de trabajo, ayuda a priorizar el trabajo, hace el coach a los funcionales, marca el ritmo, media dentro del equipo y facilita la producción en estas metodologías (ej. Scrum Master). Son conocimientos y habilidades de facilitación, coach y base metodolígica difíciles de encontrar desarrolladas. Otra habilidad que encuentro en falta es la del arquitecto de solución (funcional y no necesariamente técnico). En todas las metodologías este es un rol que hace la diferencia, pero en las meodologías Ágiles es aún más relevante mantener íntegra y útil la solución que se está construyendo y es un funcional caro que no se si las dependencias estatales han logrado desarrollar y conservar.
Hace ya un tiempo que Agustín Villena escribió en el foro Chile Agil comentarios a propósito de este post, estas son mis reflexiones al respecto:
Me gustaría hacerme cargo de algunos de los comentarios de Agustín, los cuales parten de mi experiencia de cerca de 30 años en proyectos de modernización del estado en prácticamente todos los países de la región. En los cuales en algunos casos me ha tocado actuar como enterrador y hacer el análisis post-mortem del proyecto para organismos internacionales como el Banco Mundial y Banco Interamericano de Desarrollo.
Lo primero a decir es que para analizar esto de los proyectos en el sector público hay que entender las condiciones de borde de la gestión en dicho sector (recursos humanos, contratación, recursos financieros, normativa y otros), de las cuales hago un pequeño análisis en este post – https://www.alejandrobarros.com/gerentes-publicos-se-ponen-a-prueba-las-capacidades/
Otros cosa que creo interesante analizar es porque algunos proyectos falla y cuales son sus causales, haciéndose la pregunta si un método alternativo hubiera mejorado las cosas, para esto recomiendo leer el libro Dangerous Enthusiasms (entusiasmos peligrosos) escrito por Robin Gauld y Shaun Goldfinch, en el cual se analizaron muchos proyectos de modernización en el sector salud en países anglosajones
En ciertos casos he notado que se antepone el método al resultado, como yo no pertenezco a la Iglesia de los agilistas, ni de los cascadistas, pero si me he leído casi todos sus libros sagrados y me ha tocado administrar proyectos con sus métodos, creo que los métodos tienen adoptarse en función de varios elementos: tipo de proyecto, entorno, competencias, modelo de externa luxación y otros. El método a usar debe aquel que mayor valor aporte el proceso y logre los resultados deseados.
Una confusión habitual que tenemos los informáticos es no asumir el contrato como una herramienta de gestión del proyecto. sólo preocupa al comienzo y cuando hay problemas. La práctica de clase mundial de gestión de abastecimiento se sustenta en la gestión cotidiana del contrato, y no sólo acordarse de él cuando hay problemas y/o estamos en tribunales, dicho eso es que los contratos públicos en general tienen lógicas de cascada, esto empieza hado en muchos países por el órgano contralor.
Saludos