El otro día me pasaron un enlace a una oferta de trabajo en “infojobs”, donde buscaban un evangelizador de las metodologías ágiles con experiencia y conocimientos en dinámicas de grupo, capacidad de entusiasmar, y fuerza para cambiar los procesos de una compañía.

Aunque yo defiendo la exposición de los métodos ágiles como medio para ilustrar los problemas de la ingeniería de software tradicional, creo que deberíamos ser prudentes antes de entusiasmar demasiado. Yo mismo no me considero seguidor o evangelizador de ninguna metodología, porque creo que forman parte de algo secundario. Tal vez no es el caso de la empresa que publica el anuncio, pero me precupa dar demasiada importancia a las metodologías, y me preocupa el hecho de que las metodologías ágiles sean presentadas por “vendemotos” como las nuevas balas de plata de la ingeniería de software.

¿Son las metodologías ágiles las nuevas balas de plata de la ingeniería de software? Las balas de plata son esas herramientas o inventos que cada dos por tres aparecen prometiendo simplificar drásticamente el desarrollo de software. La expresión se popularizó tras la publicación del artículo No Silver Bullet, de Frederick Brooks, donde explica por qué no existen ni existirán. Muy resumidamente, la razón es que la complejidad del desarrollo de software no reside actualmente en las herramientas, sino en los propios problemas que afronta.

No obstante, sigue habiendo muchas personas que venden herramientas o inventos milagrosos para el desarrollo de software. Los ejemplos son más numerosos de lo que parece. Desde los que dicen haber inventado máquinas que programan, hasta los que afirman que pueden fabricar software por fuerza bruta con mano de obra barata. Dentro del segundo grupo incluyo a la mayor parte de las grandes y prestigiosas consultoras, lo que da una idea de la dimensión del problema de los vendemotos y los charlatanes en el mundo de la ingeniería de software.

Las metodologías ágiles no son una excepción. Ya están empezando a ser vendidas como la nueva panacea universal. No es que las propias metodologías o sus creadores lo digan. Ni Scrum ni XP prometen ser el método definitivo que garantice el éxito en el desarrollo de software. El problema son los terceros que se dedican a venderlas.

Para empezar, creo que se concede a las metodologías mucha más importancia de la que realmente merecen. Existen demasiadas, y en ocasiones se obvia uno de los primeros y más importantes puntos del propio Manifiesto Ágil, y es que las personas están por encima de los procesos y las herramientas. Esto es clave. Ninguna metodología logra por si misma ningún resultado si no parte de personas capacitadas. Toma cincuenta monos, y por mucha metodología que apliques, el resultado será un fracaso. Por tanto, lo primero son las personas. Las metodologías son algo secundario: pueden ayudar, o pueden ser un obstáculo. Cuando las metodologías se imponen de forma dogmática, como una religión, casi siempre conducen al fracaso, ya sean ágiles o no. Esta fe ciega en las metodologías es una letanía que a mi me gusta llamar metodologitis, y un síntoma de esta inflamación son las tropecientasmil existentes: Scrum, XP, Kanban, Evo, RUP, …

Hay cosas que en cuanto salen del círculo técnico de donde proceden y empiezan a llegar como modas a la gerencia de las empresas y a la industria de los cursos y las certificaciones acaban siendo deformadas. Por ejemplo, últimamente está cada vez más de moda Scrum, y cada vez veo más demanda de personas con la certificación Scrum Master. Esto debería ser positivo, y sin embargo, se ha tornado en una amenaza para la difusión de los propios principios ágiles. Tres artículos super-interesantes al respecto escritos por Juan Palacio son los siguientes: Como cobrar 1500 dólares por un cursillo de dos días, El traje nuevo del emperador, La amenza de la certificación Scrum Master.

Pienso que en el mundo de la gerencia, de lo poco que ha llegado relacionado con la gestión ágil, hay cierta distorsión de alguno de los conceptos más elementales. Como muestra tal vez valga la siguiente presentación sobre un piloto de implantación de Scrum en Telefónica I+D. Por una parte me alegro de que los métodos ágiles sean puestos a prueba en la gran empresa, pero después de leer la presentación, parece que los métodos ágiles consistiesen en tener reuniones todos los días, poner pegatinas en las paredes, recolocar los muebles, y mantener dinámicas de grupo. Me quedo con la duda de si después de tanta reunión y tanta terapia de grupo, al final hicieron alguna entrega de código.

Veo lo mismo en otras partes. Más que Scrum, lo que se implanta es SCROB, y en vez de gente entusiasmada con los métodos ágiles, lo que obtenemos son personas hastiadas de tanta pantomima y de tanta burocracia pintada de rosa. Conclusión: creo que deberíamos quedarnos con los principios ágiles, y evitar el seguimiento dogmático de las metodologías, que como observa Juan Palacio es lo que hacen los mejores equipos.