Mis comentarios sobre "Cuando lo Agil no es tan Agil"de @abarros

Continuando la discusión desde Articulo de Opinion de @abarros "Cuando lo Agil no es tan Agil", aquí va mi versión comentada

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!

Puedo afirmar que en octubre de 2013 los metodos agiles se transformaron en Chile en palabra de moda. Hasta ese entonces, los agilistas eramos subterraneos. ¿A qué se debió? A gerentes de algunas corporaciones que viniendo de afuera de Chile pidieron lo que conocian, cursos de Scrum para los Oompa Loompa de sus empresas.

¿Saben qué? Para ser ágiles el que debe cambiar es Willy Wonka.

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.

Concuerdo con Alejandro, una vez un colega me dijo que su empresa era ágil. Cuando le pregunté por qué, me respondió : "Porque no documentamos"

Para los que no lo saben, uno de los precursores de la Agilidad, Ward Cunningham, es el creador de la Wiki, que se usó en el primer proyecto de Extreme Programming C3, y que luego sería inspiración de la más grande Enciclopedia jamás creada por la humanidad, Wikipedia.

En la Agilidad se documenta, y mucho, pero con un objetivo muy distinto al tradicional. Los últimos documentan para evitar que los clientes cambien algo. Los métodos Ágiles documentan para atesorar el conocimiento creado.

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.

Tal como expresa @leosoto, esto es totalmente a proposito en el mundo Agil, no un defecto.
Pero aun hay gente que cree que un montón de documentos reemplazará el involucramiento constante de la gente del negocio en el proyecto de software. Fantasias…

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.

Es cierto. Sin embargo en todo proyecto de los que he participado en el sector publico, aunque vengan con lógica de cascada (en realidad es lógica de comprar software es lo mismo que comprar papas) al final los contratos se terminan ajustando a la realidad: un software que funciona, si o si esta en permanente evolución. Y aunque se trate de definir todo en un documento (nunca se hace, y no sirve de nada, además) hay tanto que definir en el detalle de los proyectos que igual se puede hacer gestión de alcance variable.
Sería interesante sincerar eso de una vez por todas

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

Efectivamente, toda herramienta tiene detrás una mentalidad de gestión.
Tu puedes predecir la construcción de un edificio común, o cuanto demoraras en desarmar y armar un auto. Existe una receta. Lo impredecible es crear la receta, y eso no se ajusta a las famosas Cartas Gantt

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

Ups!! Aqui no estamos para nada de acuerdo, Alejandro

Todo sistema complejo que funciona ha inevitablemente partido de un sistema sencillo que funciona, eso lo dijo un experto en sistemas humanos, John Gall.

He visto al Estado desperdiciar tanto dinero en proyectos de software gigantescos que nacen tan complejos que nunca pueden desarrollarse bien

Y si quieren tomen el caso de healthcare.gov, desarrollado por mega consultoras que lo llevaron al fracaso, y rescatado por un grupo pequeño de ingenieros

¿Saben que los proyectos de software tienen DES-economías de escala? Todas las estadísticas de éxito del proyectos lo refuerzan una y otra vez, sin importar la metodología
Sobre “tomar la dirección incorrecta”, observo que Alejandro confunde los métodos agiles con la estrategia “en el camino se arregla la carga”. Le recomiendo este artículo de Alistair Cockburn, que muestra un componente fundamental de los métodos agiles, “Diseño como adquisición de conocimiento” http://alistair.cockburn.us/Design+as+Knowledge+Acquisition

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.

Comparo la opinión de Alejandro con la mía, después de años de acompañar equipos ágiles y varios de ellos en el sector público. veo una idealización del sector privado, que no comparto

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?

Saludos
Agustin Villena

Que buen artículo y que buen comentario del artículo.

Obviamente no estoy de acuerdo con la tablita, pero bueno, ¿quién podría estarlo? Idealmente los proyectos deben ser lo más públicos y transparentes que sea posible, esto porque a la gente le da vergüenza cometer errores en los que queda un rastro, y eso obliga a que revisen de manera más cuidosa lo que están haciendo, lo que tiene una ventaja para el proyecto: lo que ya está hecho tiene más probabilidades de estar correcto, porque más gente lo ha revisado, aunque sea de manera informal.

Es lo mismo que pasa con el open source, tiene menos bugs que el código cerrado que miran menos personas.

De modo que sea un proyecto estatal o uno privado, siempre todo debería ser lo más abierto posible.

Con eso dicho, no entendí eso de “jira-mono-canguro”… ¿qué es eso?

basicamente cuando piensas qe usando jira-agile estas haciendo agil

Ya ok, esto es jira agile

?y porque los animales? Mono, canguro???

Pq es un lema habitual de Alejandro , referido a ser algo tipo frankestein , hibrido , etc