Cuando Matin Fowler habla, yo escucho (¿qué no sabes quién es? Imposible, seguro que como mínimo has visto alguna vez su famoso libro Refactoring: Improving the Design of Existing Code)). Y esta vez Martin ha hablado alto y claro del estado del desarrollo ágil, yen particular de lo que él llama los “falso-ágiles”.

Los métodos de desarrollo ágiles están muy de moda desde hace ya algunos años pero en mi opinión, y la de Fowler, se han ido desvirtuando y perdiendo parte de las características fundacionales recogidas en el Agile Manifesto. Estamos en un punto en qué todo el mundo dice seguir procesos de desarrollo ágil aunque sea combinando prácticas ágiles (como el pair programming o el test-driven development) al tun tun.

En esta charla “Agile in 2018”, Martin Fowler reflexiona acerca del viaje de los métodos ágiles hasta ser el paradigma de desarrollo mayoritario, así como los éxitos y fracasos que la comunidad ágil ha tenido por el camino. La transcripción completa de la charla (en inglés), la tenéis aquí pero a continuación os resumo las ideas y puntos más importantes que menciona.

Los tres grandes problemas del desarrollo ágil de software

Parece que todo vaya bien en el mundo ágil. Vayas donde vayas ves gente y empresas de desarrollo software que dicen ser ágiles. Esto es un gran cambio respecto a la situación de hace 10 años. El problema es que preguntas a los “agilistas” de antaño, que ya empleaban métodos ágiles cuando este nombre no existía como tal, y percibes su inquietud y decepción.

Antes el problema era conseguir que las empresas se tomaran el desarrollo ágil seriamente. Ahora, todas son ágiles, pero cuando rascas un poco te das cuenta que lo que ellas entienden por ágil es muchas veces muy diferente de lo que nosotros consideraríamos ágil.

Nuestro desafío ya no es conseguir que la gente quiera adoptar la agilidad en el software, nuestro desafío es luchar contra lo que llamo “falsos-ágiles”. Un falso-ágil es alguien que de ágil sólo tiene el nombre pero que no sigue ni los principios ni valores de la verdadera agilidad. Casi que podemos decir que estos practicantes del desarrollo ágil van en contra todo lo que quisimos que fueran los métodos ágiles cuando hicimos el manifiesto fundacional. Ron Jeffries habla de ellos también como “Dark Agile”, o más concretamente como “Dark Scrum“.

Estamos en la época de los falsos-ágiles, que de ágiles solo tienen el nombre pero no los principios ni las prácticas - Martin Fowler Share on X
Ejemplo de lo que pasa cuando se desvirtúa el concepto de agilidad

Ejemplo de lo que pasa cuando se desvirtúa el concepto de agilidad

Para intentar ser un poco más concretos, veamos los tres grandes aspectos que resumen la problemática situación de los métodos ágiles en 2018.

Visión industrial del mercado ágil

Uno de los cuatro valores principales de la agilidad es que los individuos y sus interacciones están por encima de los procesos y herramientas. Si quieres tener éxito desarrollando software, lo más importante es encontrar gente buena, y que sea capaz de trabajar bien de forma colaborativa como un equipo. La discusión acerca de los procesos y herramientas que el equipo debería usar viene después. El equipo tiene que poder escoger su propio camino, y cambiarlo cuando quiera como parte de su evolución.

En cambio, como parte la visión industrial del mundo ágil (de la que todos somos cómplices, vendiendo nuestros cursos, consultorías, libros sobre métodos ágiles) busca imponer los métodos ágiles más adecuados a la gente, “enseñándoles” como debería ser un buen proceso de desarrollo ágil. Esto es una parodia del concepto de agilidad. Ni los más firmes defensores de los métodos ágiles deberían predicar que sus métodos son siempre la mejor opción. De hecho lo más ágil es que un equipo decida justamente no seguir principios ágiles para un proyecto concreto si creen que no es lo más adecuado. 

Importancia de la excelencia técnica

Muchas conferencias ágiles están vacías de programadores y hablan poco de las técnicas reales de creación de software. Hay que recuperaros y dar a los aspectos técnicos la importancia que se merecen. Hasta el programador JavaScript más junior tiene que estar conectado con las decisiones a nivel de negocio si queremos que la organización funcione realmente de un modo ágil.

De proyecto a producto

Tenemos que liberarnos del foco en el proyecto como unidad de trabajo. Tenemos que cambiar a una visión orientada a producto. Organizarse en torno a proyectos lleva a tener equipos temporales creados de forma adhoc para algo muy concreto. En cambio, pasar a una orientación a producto ayuda a tener equipos que continuamente trabajan juntos en una área clave para la organización. Esta visión a más largo plazo permite organizarse mejor y evolucionar para ser cada vez más eficiente y generar más valor añadido. A la larga, se reduce el tiempo de cada ciclo de desarrollo trabajando con iteraciones más cortas sin afectar a la integridad del software.

¿Hay esperanza?

Aunque hasta ahora sólo haya hablado de problemas, sigo creyendo en los métodos ágiles. Sobre todo porqué creo mucho en la comunidad que está detrás y que estoy convencido que será capaz de reaccionar y corregir los problemas que he mencionado.

Desde que creamos el Manifiesto Ágil, hemos estado abiertos a la participación de toda persona que estuviera interesada a contribuir y colaborar con sus ideas sin nunca intentar tener un papel preponderante ni intentar dirigir el futuro de la agilidad. Mientras sigamos con esta flexibilidad en la comunidad ágil, creo que seremos capaces de solucionar cualquier problema que se nos ponga por delante.