Tinselcity

El resumen más breve de lo que sigue es: Agile “no funciona”. Lógicamente hay más. Si solo tuviera eso que decir, acabaría aquí y ya está. Aún así, presento este resumen claro y directo para que los lectores más “sofisticados” puedan, si quieren, adoptar ya de entrada una actitud hostil y prepararse para contradecir y negar todo lo que sigue. Por supuesto, lo que sigue es solo mi opinión y, obviamente, estaré completamente equivocado, claro.

En el nombre de Agile

El manifiesto agile cumple 20 años. Desde entonces hasta ahora ha dejado sentir su efecto sobre la industria del desarrollo de software. Hoy en día, es casi raro encontrar una empresa o un equipo de desarrollo que no se describa como “Agile”. Sin embargo, lo que esto significa en la práctica es muy variable.

Se pueden leer en internet cientos, miles de discusiones sobre lo que significa “Agile” o “ser Agile”. Yo mismo he encontrado y vivido situaciones en las que se entendían estas ideas de formas ampliamente distantes, casi opuestas. Con el tiempo, estas diferencias han llevado a que muchos, independientemente de qué o cómo lo hagan, proclamen aplicar agile, Agile, Agile 100%, auténtico Agile, Agile pero bien, u otras muchas variedades de la expresión, intentando dar a entender que hay un “Agile bueno” y otros no tanto. Y que, por supuesto, ellos hacen el bueno.

Entendiendo el manifiesto y sus limitaciones

El manifiesto agile, el origen de todo esto, es un documento breve. Esto le da un cierto aire de sencillez, de ser algo claro y definido, que es evidente y no necesita más explicación o matización. Sin embargo es su brevedad, su aparente obviedad y sencillez, lo que más limita su alcance y lo que ha llevado directamente a la situación en la que se encuentra hoy la industria.

No merece la pena reproducirlo aquí1) pero sí creo que es interesante describir un poco qué es, cómo está formulado y -brevemente- quién lo escribe.

Qué es el manifiesto agile

Lo primero que es necesario señalar es que sólo se trata de cuatro “observaciones” o -según algunos- “principios”. Es decir, no es, ni muchísimo menos, una metodología. No es tampoco nada que derive de forma directa en una determinada metodología de desarrollo y, menos aún, en ningún proceso, regla, o actividad concreta a seguir en el desarrollo de software.

Algunos los describen como principios. Tomados así serían verdades fundamentales que deberían regir o guiar todas las conductas y actuaciones que se seguirían al desarrollar software. Desde esta perspectiva podrían teóricamente dar realmente origen a alguna metodología, proceso, etc.

Personalmente, sin embargo, no creo que puedan tomarse como principios sino como meras observaciones. En primer lugar porque es lo que son. El origen del manifiesto, el cómo surge y de quién, es poco más que tomar una serie de conceptos y dar “más importancia” a unos que a otros. La base de esta elección es poco más que la ocurrencia casual del grupo. ¿Basado en una experiencia de años? Sí, bien, podemos aceptar esto, pero la elección de unos conceptos y no de otros no está basada en una investigación de cuáles son los relevantes y cuáles no. Tampoco es fácil considerarlos “principios” porque realmente no expresan una verdad fundamental. En ningún caso dicen “esto es así” o ni siquiera “esto es mejor que esto”. Lo único que dicen es, básicamente, “después de trabajar durante unos años, se nos ocurre que nos importa más esta cosa que esta otra, esa más que la otra, y aquella más que esta de aquí”. Encima, para hacerlo más indiscutible2), añaden explícitamente una matización: “Que no es que esas otras cosas no importen o importen poco, sólo queremos decir que estas nos importan más”.

Es importante tener clara esta expresión del manifiesto agile para poder entenderlo. Si no, podemos llegar a extremos tan estúpidos como los de algunos que he visto en primera persona que terminan diciendo cosas como “Pues yo he estado leyendo muchísimo sobre agile y he hecho un curso y agile dice que no documentación para justificar cualquier ocurrencia que les apetezca.

También creo que es interesante tener una cierta idea de quién formula el manifiesto. Los 17 autores/firmantes del manifiesto se presentan como “desarrolladores experimentados”. Algunos comentan, justificando esa experiencia, que muchos de ellos, si no la mayoría, en aquel momento activamente escribían código. No tengo ningún interés por ponerlo en duda, pero creo que también es relevante señalar que una buena parte no y que, la mayoría, por no decir casi todos, al poco tiempo estaban trabajando en puestos de “gestión”, en consultoría, dando charlas, escribiendo libros… sobre gestión, sobre organización, sobre sus metodologías concretas.

Esto último es relevante no tanto por invalidar su experiencia o su intención -algo que no quiero hacer- sino por dos detalles. El primero es que de un modo u otro, la mayoría tenía o estaba desarrollando sus propias ideas o metodologías de desarrollo, posiblemente con puntos comunes con el manifiesto, por supuesto, pero también siguiendo aplicaciones e intereses potencialmente diferentes. En segundo lugar es relevante señalarlo porque es precisamente esa diferenciación entre el manifiesto -genérico, vago, y abierto- y esas otras metodologías -mucho más específicas, restrictivas y concretas-, uno de los principales factores de confusión sobre lo que significa o no el uno y las otras.

Finalmente, y lo señalo de forma breve porque no necesita mucha más explicación, puede ser relevante fijarse en que la mayoría de esas nuevas metodologías o ideas que van a proponerse y surgir del movimiento agile tienen, originalmente, una premisa común que se pasa por alto demasiado fácilmente: Equipos pequeños. Muchas veces por su origen experimental en el que surgen, pequeños proyectos no críticos donde se permite más fácilmente probar nuevas soluciones pero que habitualmente se limitan en presupuesto a equipos generalmente poco numerosos (5, 10, raramente más de 20 personas). Esto tendrá su relevancia después.

El ideal rebelde

También es importante entender la naturaleza rebelde del manifiesto agile. Buena parte de la motivación del mismo no está tanto en una búsqueda, podríamos decir limpia, de unos ideales o de unas verdades fundamentales, cuanto en una oposición a ciertas situaciones del momento en el que surge.

El manifiesto agile surge tras unas décadas de metodologías basadas principalmente en grandes planificaciones y rígidos procesos un poco al estilo de las grandes obras de ingeniería y construcción. Se intentan aplicar al desarrollo de software metodologías de gestión que ciertamente son poco aplicables y producen múltiples problemas adicionales. En general, el principal problema que tienen aquellas ideas es que el desarrollo de software no solo es joven y menos establecido sino que plantea unas dificultades en su producción muy diferentes a las de las obras de construcción. Así, muchos proyectos terminan con enormes desviaciones, no solo de tiempo y presupuesto, sino muchas veces desviaciones en su capacidad para solucionar el problema original. En palabras más simples: Cambia la situación antes que el proyecto se complete, haciendo que la solución ya no sea buena o, en algunos casos, siquiera aplicable.

En los años que llevan al manifiesto, crece la insatisfacción con esa situación y se buscan metodologías, procesos, prácticas, que de algún modo ofrezcan una alternativa mejor. Estas son cosas como RAD, (R)UP, XP, Scrum y otras. Algunas de estas, aunque hoy consideradas “metodologías agile” son anteriores al manifiesto. Lo interesante es que todas estas no son, en ese momento, nada probado ni establecido como claramente efectivas. Algunas son principalmente teóricas, otras apenas están siendo desarrolladas y no han sido aplicadas aún, otras, finalmente, son casi más un producto comercial específico que una metodología general. El propio manifiesto, en su primera línea reconoce el terreno inestable y aún por explorar que pisa: “Estamos descubriendo mejores formas de desarrollar…”.

En cualquier caso, es sobre estas metodologías sobre las que surge el manifiesto. Más o menos como una forma de querer extraer de todas ellas un llamamiento, de crear un movimiento de ruptura con las otras, anteriores. Este matiz de ruptura y de llamamiento a la acción, quedarán ahí en el fondo, como un sutil pero efectivo aliciente subliminal para “ganar adeptos”.

La interpretación de las escrituras

Quizá el problema intrínseco más importante en cualquier movimiento filosófico, político, religioso, ideológico en general, es el de la interpretación de las escrituras. Ocurre así:

Es fácil y habitualmente ya viene incluido como parte del inicio del movimiento ideológico, producir un manifiesto, un ideal, una constitución3), un libro sagrado. Pero precisamente por su naturaleza, un documento así tiende de forma natural a ser abierto e impreciso, a plantear solo lo fundamental y dejar los “detalles prácticos” para su posterior interpretación. Esto, como digo, casi siempre ocurre de manera natural.

El manifiesto, la constitución, libro sagrado, declaración, etc, van a definir el carácter general del movimiento, las verdades en las que, como movimiento, cree el grupo. Pero va a ser la interpretación de las escrituras la que defina en términos prácticos la evolución, la organización y la actuación del grupo en sí mismo. Una misma idea fundamental, interpretada de un modo o de otro, empujada un poco más hacia aquí o un poco más hacia allá, puede dar lugar a aplicaciones notablemente distintas.

El manifiesto agile es, como ya he dicho, escueto y extremadamente abierto. No dice nada que haya que hacer, ni nada que haya que evitar. No señala ningún objetivo concreto a alcanzar, ni ningún camino específico a seguir para alcanzarlo. Y a la vez, cada uno de sus autores parte desde ahí, por su propio camino, interpretando esas ideas de la forma específica que él prefiere.

Esto va a ser lo que lleve directamente la la situación actual. Esta total apertura de interpretaciones hace que literalmente cualquiera, con una mínima habilidad retórica, pueda derivar una metodología, una aplicación práctica, asegurando que se basa ideológicamente en los principios / observaciones genéricas del manifiesto.

Metodologías y personas

Cualquier movimiento ideológico -y eso es lo que hemos establecido que es esencialmente Agile, un movimiento ideológico con unos fundamentos particularmente vagos y abiertos a interpretación- atrae diversos grupos de personas.

No me gusta, normalmente, clasificar o encasillar a las personas en grupos estereotípicos. Prefiero plantearlo mejor por motivaciones. Una persona concreta puede encontrarse representada por más de una única motivación o puede cambiar sus motivaciones a lo largo del tiempo. De forma muy general, he encontrado unas pocas motivaciones por las que la gente se acerca al movimiento agile o a las metodologías derivadas4) de él.

Las bases

Una parte de las personas que deciden aplicar una “metodología agile” lo hacen con una actitud general de creyentes de base. Oyen, leen, ven lo que les dicen y les enseñan y simplemente lo aceptan. Es una aceptación simple. No le buscan más justificación. A veces porque no tienen experiencia para valorar nada más que lo que les han presentado. Otras porque han sufrido ya el fracaso de otras propuestas; así, sea pensando que peor no puede ser o sea porque realmente crean que será mejor, acuden a una nueva alternativa. Y casi siempre lo aceptan porque, de todos modos, no tienen ningún poder de decisión en el asunto.

Otra motivación es una creencia de algún modo más profunda, más convencida. Algunos invierten tiempo y esfuerzo en entender bien qué es cada cosa, qué significa y cómo se debe aplicar correctamente. Creen más firmemente en que es bueno, pero no es una aceptación sin más, sino que reconocen los esfuerzos que se deben hacer y, en algunos casos, incluso las limitaciones que pueden encontrar.

Todos estos pueden trabajar en desarrollo o en gestión, indistintamente. La decisión de usar una metodología u otra casi nunca es suya; algunas veces sí pero en esos casos lo hacen siguiendo la indicación o el ejemplo de otros. Sea como sea, generalmente estos grupos el único efecto que tienen sobre la evolución del movimiento es el de hacerlo crecer. Es, podríamos decir, el grupo de usuarios.

Los intelectuales

Es habitual también que exista una especie de élite intelectual. Su motivación principal es ser los guardianes del movimiento. Creen en él bien porque es suyo -lo han originado ellos- o bien porque lo han hecho suyo. Su palabra, su interpretación del manifiesto es “la correcta”. En este caso claramente son mayormente los firmantes originales del manifiesto los que forman este grupo. La mayoría de ellos -fueran o no desarrolladores activos en su momento- ahora viven de ser ideólogos, de llevar a un sitio u otro lo que es la auténtica interpretación y comprensión de la ideología.

Si los anteriores eran los usuarios, estos serían los vendedores de la ideología.

Los interesados

Este es el grupo que, a la larga y definitivamente, termina siendo el responsable real del movimiento. Es, en cierta forma, el grupo de “mandos intermedios” del movimiento. Son quienes no solo deciden, sino los que activamente promueven el movimiento dentro del ámbito en el que tienen autoridad para hacerlo. Este puede ser un departamento, una empresa, un club, un sub-movimiento, o también un público, una audiencia.

Su papel es el de compradores, por decirlo de alguna forma, son quienes implantan la aplicación de una metodología u otra en ese entorno, aunque puedan ser o no usuarios también.

Comprar y vender ideologías

Y aquí es donde finalmente está el problema fundamental de Agile.

Una ideología se presta a que ese grupo que compradores, de interesados, se decida por una o por otra interpretación según esta sirva mejor a sus intereses, y estos demasiadas veces no están necesariamente en línea con las intenciones originales.

En este caso, confluyen tres factores que han interactuado para producir la situación actual:

  • La ideología original es muy abierta, muy poco restrictiva.
  • La industria es joven, intelectualmente inestable, todavía lejos de haber encontrado soluciones claras y generales.
  • El proceso de desarrollo en sí es, de algún modo, todavía demasiado desconocido para los clientes.

Con estas tres cosas como punto de partida, esos interesados han encontrado en agile -en general- un filón fácil. Por un lado, en el nombre de agile, se implantan sobre los desarrolladores toda una serie de prácticas con más o menos sentido, sirvan o no, se apliquen bien o no. Por otro, se presenta ante los clientes como una promesa de mejoras y beneficios, la mayoría de ellos inventados con poca o ninguna base real. En el fondo el problema es clásico: bienintencionados por un lado, confiados por otro, y listillos en medio aprovechándose de los otros dos.

Agile hoy

Agile, hoy, es poco más que una palabra de marketing, una forma de proclamar y vender que “haces las cosas bien”, sin explicar mucho qué quiere decir eso de “bien”. Por otro se ha convertido justo en lo que pretendidamente quería solucionar: Es una serie de procesos, de ceremonias, de herramientas puramente de gestión, que sirven para que el control sobre los proyectos vuelva a estar -o siga estando- en manos de quien siempre ha estado, de los gestores.

¿No te gusta? Es que no lo has entendido...

Todo lo dicho anteriormente, en realidad, no pretende criticar ninguna de las débiles y vagas ideas que proclama el Manifiesto Agile. Incluso siendo débiles y vagas, no tengo nada que reprochar a esas ideas. Están hechas para que sean irreprochables. Son “obviamente razonables”. Presentarlo como una proclama sí me parece bastante estúpido. O quizá más que estúpido, me parece poco útil. Y me parece que tal como es y ha sido, sus efectos finales probablemente suman casi más en negativo que en positivo.

También creo que el modo en que esas ideas están presentadas ha hecho mucho daño. Decir “prefiero X antes que Y” por mucho que después digas “pero también Y, eh”, hace inevitablemente que mucha gente sacrifique casi completamente Y solo para darle prioridad a X. Y eso me parece muy claramente una muy mala idea.

Y aún así, no digo que no haya supuesto ninguna cosa buena, ni que algunas de las propuestas hechas por sus defensores no me parezcan buenas. Me lo parecen. Estoy convencido de que lo son. Algunas. Pero también estoy muy convencido de que “en el nombre de Agile” como mínimo se han hecho tantas estupideces y se han permitido tanto despilfarro y tantas malas prácticas, como se han producido buenas.

Feliz aniversario, estúpido manifiesto agile.

1)
basta seguir el enlace dado
2)
Podría decirse incluso que para cubrirse las espaldas
3)
“ley fundamental o fundacional”
4)
o no tanto