20 años de agilismo, ¿y ahora?
El 17 de Febrero de 2001, un grupo de reconocidos eruditos de la industria cansados de trabajar con rígidas metodologías en cascada decidió declarar un “Manifiesto sobre desarrollo ágil de software” (o Manifesto Agile en la informalidad), que originalmente parecía una lista de deseos pero que con el tiempo demostró ser la base de todo un movimiento que ha ganado adeptos y detractores por igual y que sin embargo se ha consolidado en la industria de IT como el estándar a seguir. No obstante creo que es tiempo de preguntarnos: ¿Las metodologías ágiles son realmente útiles o seguimos con los mismos dolores de dos décadas atrás? ¿Las empresas de IT han adoptado el manifiesto Agile como parte de su cultura o es sólo un movimiento de marketing para captar talentos? ¿Qué significa ser ágil?
¿Agile es humo?
Muchos detractores del agilismo consideran que las metodologías ágiles no han resuelto los problemas que usualmente se enfrentan los desarrolladores, en definitiva hay un requerimiento escrito en alguna parte, muchas veces mal analizado, muchas veces poco entendido, poco desarrollado y poco testeado y en producción la funcionalidad no hace lo que el cliente esperaba. Esto sigue pasando, el agilismo no logró desterrar las malas implementaciones y es muy probable que no lo logre jamás. Entonces, ¿por qué seguimos insistiendo en aplicar metodologías ágiles?
Si implementamos el agilismo sólo porque otras empresas en la industria también lo hacen, entonces claramente no entendimos el manifiesto, la intención primaria del manifiesto era hacer un llamado de atención a la industria de que la forma “normal” de trabajo de esa época no era la adecuada y que había que prestar atención a otros aspectos que sí eran críticos, a saber:
- Personas e interacciones sobre procesos y herramientas: desde los orígenes del Taylorismo, había una concepción muy marcada en que la mejor forma de producir en términos de eficiencia y eficacia era definir procesos y estándares muy estrictos, medibles y que los empleados debían adaptarse a ellos, ya que estaba científicamente comprobado que era la mejor forma de trabajar. Y, aunque en sistemas repetitivos orientados a la producción en masa, el Taylorismo demostró cierto nivel de éxito, en otras áreas como IT era evidente que ningún proceso o herramienta era realmente efectivo porque la naturaleza del trabajo dependía mucho de la comunicación entre las personas más que del proceso subyacente. El sistema de producción de Toyota, por otro lado, ya había reconocido hacía varias décadas atrás que uno de los pilares para ser exitosos eran las personas y no los procesos y llevaba igual cantidad de tiempo trabajando o mejorando en pos de estos principios. Implementar una metodología ágil sin entender que las personas y sus interacciones son claves para llevar adelante un proyecto, es adolecer de una anticuada visión Taylorista del trabajo que nada tiene que ver con el agilismo.
- Software funcionando sobre documentación extensiva: también relacionado al punto anterior, las metodologías en cascada se habían adoptado de procesos aplicados en áreas militares, donde la rigidez y el detalle exhaustivo eran esenciales antes de poder arrancar un nuevo proyecto. Llevado al software, se requerían hojas y hojas de casos de uso explicando cada flujo, cada regla de negocio, cada requerimiento no funcional antes de poder escribir una sola línea de código. El contrato debe estar firmado y detallar cada aspecto que entra dentro del alcance de nuestro proyecto con estimaciones basadas en hojas escritas y supuestos. Como resultado, el desarrollo arrancaba muy tarde, con requerimientos que muchas veces ya habían cambiado y el despliegue en producción sólo se podía hacer cuando todo lo que constaba en el contrato estaba terminado, de modo que constantemente se incurría en incumplimientos contractuales y clientes enojados. La documentación excesiva hace perder el foco de lo que realmente genera valor para el cliente, que no es más ni menos que el software funcionando.
- Colaboración con el cliente sobre negociación contractual: los contratos muchas veces adolecen de la inflexibilidad de cambiar el alcance ante nueva información o nuevas condiciones y, en esa rigidez, no se prioriza lo que realmente necesita el cliente. Las necesidades no son inmutables, la pandemia nos ha enseñado esto a fuerza de negocios que se caen o mercados que emergen con fuerza, la adaptabilidad es clave para sobrevivir en un mundo altamente globalizado y los proyectos de software no son extraños a esta realidad. La colaboración con el cliente en intentar ser un compañero estratégico para ayudarlo en adaptarse rápidamente se ve de cierto modo restringida si sólo nos limitamos a hacer lo que ha sido firmado y pedido en un contrato. Si la necesidad cambió y el contrato debe adaptarse, entonces es clave tener la rapidez y flexibilidad para lograr esa colaboración sin requerir un largo proceso de aprobaciones contractuales y negociaciones ad eternum.
- Respuesta ante el cambio sobre seguir un plan: ningún plan en el desarrollo de software está escrito en piedra, los imponderables surgen incluso en los proyectos más pequeños, gastar tiempo en planes detallados es no entender la naturaleza del desarrollo de software como disciplina. Un plan es una idea de cómo creemos que vamos a trabajar con la información que disponemos hoy en día, pero no es una receta que no puede cambiar. Los sistemas complejos generalmente se ven afectados por múltiples variables que se ejecutan en forma impredecible, entonces ¿cómo podemos suponer que tenemos un plan infalible para poder ejecutar un proyecto? Lo mejor que podemos hacer es suponer que vamos a responder rápido y ajustaremos el plan cada vez que obtengamos información nueva que nos obligue a repensar nuestra estrategia.
Agile es Marketing
Es innegable que los valores del manifiesto Agile siguen con la misma vigencia que tenían hace 20 años, ¿entonces por qué seguimos renegando de ellos? ¿por qué las empresas insisten en decir que son ágiles cuando no lo son?
En mi experiencia esto se da por varios motivos, muchas veces ligados a empresas cuya cultura no ha evolucionado al mismo ritmo que el mercado o que ven en el agilismo como una estrategia más de venta que como un elemento de su propio ADN.
En estos contextos es usual encontrarse con:
- Empresas que creen haber encontrado el “proceso ideal” con prácticas que fueron exitosas en otros clientes o proyectos y fuerzan a su implementación en otros contextos. Son incapaces de admitir errores o proponer mejoras, generalmente tienen rígidas estructuras jerárquicas que no admiten cuestionamientos.
- Empresas que dicen ser ágiles pero no invierten en capacitaciones ni en promover la implementación de metodologías ágiles. Generalmente surgen pequeños grupos con iniciativas solitarias pero que mueren como experimentos aislados, con escaso soporte de los mandos medios y sin mayor repercusión.
Un factor común de ambos es no fomentar una cultura de trabajo en equipo, colaboración constante y mejora continua, es usual escuchar discursos como “así trabajamos acá”, “hemos crecido haciendo esto” o el famoso “hagamos un comité para proponer mejoras” donde ninguna acción concreta se va a llevar a cabo por falta de recursos o interés. En estos contextos es claro que no existe una cultura ágil y ahí es donde la agilidad es sólo marketing.
¿Y entonces qué es ser ágil?
El agilismo como experimento acotado a un proyecto y de unas pocas personas o como verticalazo no tiene mayor futuro que seguir implementando metodologías en cascada en pleno 2021. El agilismo, para ser exitoso y que no sea visto como humo o marketing, debe ser entendido como motor de mejoras y de generación de equipos de alto desempeño que agregan valor constantemente, acompañados por una estructura organizacional que lo fomenta y lo acompaña. Si entendemos que ese es el camino, no importa si aplicamos Scrum, Kanban o cualquier otra metodología, lo importante es que cada equipo implemente lo que mejor se adapte a su situación sin perder nunca de vista los valores del manifiesto Agile.
