Metodologías ágiles: mitos & realidades

Las metodologías ágiles, prácticas opuestas a los procesos rígidos, y aplicadas desde hace casi diez años en el mundo, todavía generan resistencia basada en mitos que aquí tratamos de derribar. Thomas Wallet, de Pragma Consultores, brinda aquí un análisis en tres partes, que incluye sugerencias y consejos para implementar estas metodologías de manera efectiva y no cometer los errores típicos. La mirada de los que ya las instrumentaron en forma exitosa.

Por: Thomas Wallet*

El término “ágil”(de “agilizar”), que la Real Academia Española define como “dar rapidez y facilidad al desarrollo de un proceso o a la realización de algo”, fue elegido en 2001 por un grupo de pensadores disidentes del mundo del software para calificar sus metodologías. A través del denominado -y ahora mítico-Manifesto Agile, declaran valorar más los individuos e interacciones por sobre los procesos y herramientas.

Además, priorizan el software que funciona, más que la documentación exhaustiva; aprecian la colaboración con el cliente, más que la negociación de contratos; y rescatan la respuesta ante el cambio, antes que el seguimiento de un plan. Casi una década después, estas metodologías “ágiles” han sido aplicadas en miles de proyectos de software en todo el mundo. Extreme Programming (XP), Scrum, Lean y Kanban son probablemente las metodologías ágiles que más se usaron en la última década, pero siguen prevaleciendo mitos y malas interpretaciones que dificultan su adopción exitosa. Los tres actos de esta nota intentan refutar los principales prejuicios que suelen aparecer a la hora de emprender el camino hacia la agilidad.

Primer acto

El primero de los mitos con el que uno se encuentra cuando comienza a hablar de metodologías ágiles es éste: “Es demasiado nuevo y son pocos los que lo usan”. Lo cierto es que a pesar de que estas metodologías se han puesto de moda hace poco, especialmente en la Argentina, tienen varios años y sus procesos han sido probados repetidamente. Repasemos algunas fechas importantes:

• La piedra fundamental de Scrum fue publicada hace 23 años por Hirotaka Takeuchi e Ikujiro Nonaka, y el primer proceso de este tipo fue concebido, ejecutado y documentado por Jeff
Sutherland, John Scumniotales y Jeff McKenna hace 16 años.
• Extreme Programming fue concebido y aplicado por Kent Beck, Ron Jeffries y Ward Cunningham en el proyecto Chrysler Comprehensive Compensation System, hace 13 años. El método test-first development fue usado hace 50 años en el proyecto Mercury de la NASA.
• Los principios de Lean, llevados al desarrollo de software por Tom y Mary Poppendieck, fueron publicados hace sólo seis años. El concepto de Just-In-Time, uno de los pilares de Lean Manufacturing, fue introducido por Toyota en la industria automotriz hace 75 años.
• Kanban tiene sus orígenes en los sistemas mercantiles japoneses de hace cinco siglos. Luego fueron aplicados por Toyota en su principal planta de producción, hace 56 años.

Para dar una idea de la amplitud de la comunidad agile en el mundo, basta sólo con buscar en Internet la cantidad de menciones del término.

Para tomar un ejemplo cuantitativo, la Scrum Alliance ya registra oficialmente más de 64.000 Certified Scrum Masters (personas que tomaron el curso oficial) y más de 2100 Certified Scrum Practicioners (personas que son CSM y que demostraron haber aplicado Scrum
durante más de un año). Del lado de Extreme Programming, si bien no se consiguen números precisos de adopción, la comunidad también es muy numerosa y se habla de decenas de miles de proyectos en el mundo usando las prácticas de XP, en dominios tan variados como el de telcos, media, banca, finanzas, seguros, ERPs, defensa, Internet, salud o entretenimiento.
Basándonos en este mito y su refutación, aconsejamos:

1. Aprovechar que las prácticas ágiles están de moda para convencer a su organización de probarlas.
2. Apoyarse en las experiencias existentes para no tener que “reinventar la rueda”.
3. Hacerse acompañar por personas experimentadas y así evitar errores típicos.

Segundo acto

El otro mito imperante es: “Esto no nos va a servir, somos demasiado especiales”. Casi todas las organizaciones se consideran únicas a la hora de decidir si introducen prácticas ágiles. Creen que la estructura, el contexto, el proyecto, el equipo o los usuarios tienen características tan específicas que van a impedir la adopción. Otro argumento que se suele escuchar es que las prácticas ágiles podrán ser muy buenas para equipos chicos en un mismo sitio, pero seguramente no escalan para equipos de centenares o miles de personas distribuidas.La realidad es que, en el mundo de los negocios actual, cualquier organización y proyecto es único y tiene su propio contexto. También es cierto que la adopción de prácticas ágiles suele chocar contra algunas características existentes de cada organización. En ámbitos con estructuras jerárquicas muy establecidas, el principio de equipos autogestionados de Scrum suele incomodar. Las prácticas ágiles (en particular Scrum, Kanban y XP) son difíciles de enmarcar en contratos con alcances fijos y detallados. Dicho esto, hay que remarcar que las prácticas ágiles requieren un cambio de paradigma y que las organizaciones más “conservadoras” en su cultura tendrán mayores dificultades a la hora de implementar dichos cambios. Es lo que remarca Stephen R. Covey en su muy pragmático principio: “Si seguimos haciendo lo que estamos haciendo, seguiremos consiguiendo lo que estamos consiguiendo”. Respecto del escalamiento en organizaciones grandes, si bien es cierto que varias prácticas ágiles fueron pensadas para equipos de menos de diez personas, hace tiempo que existen mecanismos probados y eficientes para poder aplicarlas con éxito en grupos de cierto tamaño. Yahoo, 3M, BBC, Nokia, Primavera, Amazon, Google, Microsoft y Boeing son algunas de las empresas que aplican estos conceptos a mayor escala. Yahoo, en particular, afirma haber aplicado Scrum en un proyecto con 700 desarrolladores. En resumen, considerando este segundo mito, recomendamos:

1. Elegir qué prácticas ágiles se adoptarán de inmediato y cuáles tendrán que adoptarse más adelante (por ejemplo, empezar por prácticas de test automatizado en integración continua de XP, dejando para una segunda etapa las más resistidas, como programación de a pares).
2. Implementar cada práctica a paso firme, mostrando y difundiendo los logros. Es fundamental reevaluar constantemente por qué sí o por qué no estamos implementando cada práctica.
3. Empezar con experiencias piloto en grupos reducidos para afirmar los valores y beneficios de las prácticas ágiles y luego definir formas de escalamiento hacia áreas o grupos más grandes.

Tercer acto

La última de las máximas que se escucha habitualmente es: “Agile va a solucionar tus problemas de inmediato”. Se suelen tener elevadas expectativas al implementar prácticas ágiles, esperando que sea una solución mágica que borre rápidamente problemas recurrentes en la empresa. ¿Qué nos muestra la experiencia? Que es cierto que uno puede apoyarse sobre ellas para dejar al descubierto los principales problemas de la organización para desarrollar software. La mala noticia es que el camino es difícil y que ninguna metodología agile es mágica. Al proponer un marco con iteraciones de duración igual o menor a un mes, en el cual cada equipo compromete un incremento de funcionalidad en un software que sea de valor para el negocio, se ponen en evidencia rápidamente los impedimentos que ponen en riesgo dichos acuerdos.
Scrum propone una actividad sistemática de retrospectiva al finalizar cada iteración, en la que el equipo intenta identificar los principales obstáculos que dificultaron su trabajo. Estos impedimentos pueden revelar, por ejemplo, limitaciones del equipo, problemas en la relación con el cliente/usuario y conflictos en la organización. La parte difícil es actuar sobre los problemas emergentes que implican gestionar cambios culturales arraigados. La transparencia y la visibilidad que aportan las metodologías ágiles para todos los actores involucrados (equipo, management, clientes, usuarios) resultan difíciles de “digerir” por algunas personas. Varias de las prácticas de Lean (“Eliminar los residuos”, “Ver el conjunto”, “Crear la integridad”) permiten llevar a cabo una reflexión completa sobre el fundamento de cada actividad de un proceso, tratando de eliminar todos los pasos que no aportan valor y que suelen relacionarse con la burocracia. Estos impedimentos suelen trascender el mero ámbito del desarrollo de software e involucrar una visión transversal a todo el negocio de una empresa, implicando mejoras a articular entre múltiples sectores.

Por esto, sobre esta tercera máxima, proponemos:

1. Estar preparados para el momento en que se “saquen los trapitos al sol”.
2. Trabajar en las formas de reaccionar, reflexionar y emprender iniciativas de mejora.
3. Pensar a los equipos ágiles como laboratorios donde probar variantes con un riesgo limitado.
4. Tener iteraciones cortas que permitan cometer errores con impacto moderado (una sola iteración) para aprender.
5. Ser permeables al error como mecanismo eficaz de aprendizaje.
Como dice el proverbio, “Aquél cuyo pie resbala, muestra el camino para muchos”.

Epílogo

El camino de adopción de las prácticas ágiles es diferente en cada organización: para algunos, es un camino complicado y largo, y para otros la transformación resulta más natural. A veces la simplicidad de las prácticas ágiles facilita una adopción rápida, y otras veces las transformaciones culturales requeridas generan resistencias difíciles de sortear. A lo largo de esta obra de tres actos, vimos varios consejos que pueden ayudarnos a obtener resultados reales y a no esperar milagros ni beneficios mágicos. De cualquier forma, la experiencia demuestra que los logros y beneficios que se construyen a través de las prácticas ágiles justifican cada paso en el camino. Así que el último consejo (¡ya fueron demasiados!) es: ¡animarse a probar!

Ahora sí, a caminar hacia la agilidad, de a un paso a la vez.

* Pragma Consultores

Manifiesto Ágil