Varias veces he leído por ahí que “esta empresa trabaja con agilismo”, y a la hora de ver los esfuerzos que han hecho para adoptarlo, creo que ha fallado su adopción, en parte por creer que ser ágil es convertir algo en desordenado, siendo que el origen es todo lo contrario.
El agilismo es una concepción del desarrollo de software distinto, por lo cual, hay una pequeña responsabilidad en indicar qué no es agilismo:
- Una forma de codificar software de forma distinta: este método no te inculca buenas prácticas de codificación; si eres un mal programador/codificador, seguirás siéndolo a pesar que uses agilismo.
- Un método para duplicar el tiempo de la gente: no, no duplica el tiempo de nada, es más, requieres un poco más de tiempo por los pasos propios de la metodología.
- Una bala de plata cuando las cosas van mal: si tu proyecto va mal encaminado en tiempo, seguirá estándolo aunque lo uses como último recurso.
- Un movimiento hippie donde todos nos tomamos de las manos y cantamos canciones de protesta contra el desarrollo en cascada: cada realidad es distinta y cada grupo de trabajo asume los desafíos en forma distinta, por lo cual pensar que el agilismo resuelve el mundo es un pensamiento que hay que revisar.
De partida, el agilismo es una metodología para enfrentar el proceso de creación de software que nace desde una mayor interacción humana entre el equipo de trabajo, los clientes y sus necesidades concretas.
Así mismo, como todo método de trabajo, implica compromiso del equipo de trabajo, y ese compromiso debe ir con otra cualidad importante perseverancia. Ambas cuestiones, desde el punto de vista del equipo, son básicas para hacer que el método sea útil (no diré “funcione”). Esta forma de trabajo debe instalarse como una cultura de trabajo y no como un método para crear software, ya que el involucramiento de personas fuera del equipo (clientes) y la creación de puestos nuevos no-orgánicos (Product Owner) debe nacer como una necesidad del proceso de creación y no sólo por “adoptar el método”, además de respetar los pasos por muy burdos que sean.
Por último, recordar que este método es iterativo y reflexivo: tiene formas de hacer evaluaciones más continuas en el tiempo, lo cual permite mejorar los procesos y cambios en las próximas iteraciones dentro del desarrollo.
Así que la próxima vez que le diga “usamos agilismo para duplicar nuestra producción [de código]”, sea escéptico… quizás esté usando mal el término.