Agilidad ¿Medio o fin?
- Daniel Sachi
- 26 sept
- 3 Min. de lectura
La agilidad no es una varita mágica: si no sabes para qué la usas, su magia se volverá en tu contra
La agilidad como herramienta y no como destino
Todos los que leen a menudo mis notas saben que tengo mi corazoncito con las metodologías ágiles, y de hecho, con mi equipo diseñamos una propia: ROI Agile Methodology, que es una suma de mejores prácticas de SCRUM, Kanban, Lean y TQM, agregando la toma de decisiones estratégicas sobre los proyectos y las revisiones de resultados y encuestas de satisfacción profundas, posteriores a las entregas.
Sin embargo, nunca tomé la agilidad como un fin en sí mismo, sino como un medio para conseguir objetivos en plazos más cortos, con más calidad, mayor capacidad de reacción y más satisfacción del cliente, sea este interno o externo.
¿Tu organización está usando la agilidad para alcanzar objetivos claros o simplemente porque está de moda?
El cambio de paradigma que muchos olvidan
Usar la agilidad tiene como condición un cambio de paradigmas y un ajuste de expectativas.
Muchas veces, al no conseguirse estos aspectos, la metodología se vulnera, se desacredita y termina en desuso.
Pongamos un ejemplo: un gran sistema aplicativo (software), con muchos puntos funcionales y varios equipos trabajando en diferentes niveles.
Si vamos por el lado de las entregas al cliente, lo lógico es que en cada iteración se liberen funciones base que tengan sentido, que aporten valor y comiencen a generar retorno de inversión.
Algo que, en metodologías predictivas, generalmente recién se ve con el paquete completo funcionando.
El dilema del mantenimiento y la producción
Todo parece correcto hasta aquí, pero aparece un detalle crucial: si liberamos funciones al cliente, surge la necesidad de equipos para el mantenimiento de esas entregas.
Lo más lógico es que los mismos equipos se ocupen, porque son quienes mejor conocen lo que construyeron.
Pero los recursos humanos preparados son limitados y crear nuevos equipos rápidamente no siempre es posible.
Resultado: a más funciones liberadas, más bugs, más tickets y más horas de mantenimiento.
Y así, la curva de producción desciende, no porque el equipo trabaje mal, sino porque su tiempo se consume en apagar incendios.
¿Tu organización mide el impacto real del mantenimiento en la velocidad de sus equipos?
El impacto en los usuarios
A esto se suma el universo de usuarios: cuanto mayor es, más pruebas y más recorridos hacen.
Y claro, más críticas se vuelven las fallas.
Si estas no se resuelven rápido, los usuarios se cansan, dejan de creer en la solución, dudan de lo que reciben y disminuye la motivación.
El resultado es simple: un mal negocio para todos.
¿Es culpa de la metodología?
Definitivamente, no.
Es culpa del mal uso, de la falta de criterio al decidir qué liberar y qué dejar en un laboratorio con un grupo pequeño de clientes hasta que esté suficientemente probado.
Como cualquier recurso, la metodología ágil exige no solo aplicarla en la forma, sino también con sentido común para saber hasta dónde arriesgarse.
¿Tu equipo tiene criterios claros sobre qué liberar y cuándo?
Lo mismo pasa con metodologías predictivas
¿Esto no pasa con PMI o Prince2?
Por supuesto que sí, aunque de otra manera.
Cuando se libera un paquete completo, los problemas aparecen de golpe y con frecuencia se suma otro agravante: lo que se pidió al inicio ya no coincide con lo que se necesita al momento de la entrega.
Además, muchos de los recursos originales son reasignados, lo que dificulta responder a los problemas que surgen tras la implementación.
Entonces, ¿qué significa ser ágil?
Ser ágil es una forma de encarar la tarea y no el objetivo de una organización.
Su elección depende de lo que tengamos que hacer y del propósito que persiga cada empresa.
¿Tu organización tiene claro para qué quiere ser ágil o solo sigue una tendencia?
Concluyendo
La agilidad no es un fin, es un medio.
Adoptarla sin un propósito claro es como subirse a un tren sin saber a dónde queremos ir: se avanza, sí, pero hacia un destino incierto.
Una organización debe definir primero para qué quiere ser ágil; de lo contrario, lo único que logrará será acelerar el desastre.
La agilidad mal entendida no salva empresas: las hunde más rápido.
Comentarios