Todos los que leen a menudo mis notas, saben que tengo mi corazoncito con los marcos ágiles, y de hecho, con mi equipo diseñamos uno, ROI Agile, 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 encuestas de satisfacción posteriores a las entregas, asíc omo la verificación de beneficios obtenidos.
Sin embargo, nunca tomé la agilidad como un fin en sí mismo, sino como un medio de conseguir objetivos en plazos más cortos, con más calidad, más capacidad de reacción y mayor satisfacción del cliente, sea este interno o externo.
Usar la agilidad tiene irremediablemente como condición un cambio de paradigmas y un ajuste de expectativas. Muchas veces estos aspectos, al no ser conseguidos, vulneran el marco de trabajo, lo desacreditan y lo hacen caer en desuso.
Pongamos por ejemplo un gran sistema aplicativo (software), con muchos puntos funcionales, varios equipos trabajando y anidados en distintos niveles (aplicable a cualquier otra cosa compleja a construir).
Si vamos por el lado de las entregas a cliente de elementos funcionando, trataremos de tener en cada iteración un compendio de funciones base que tengan un significado para él, y que le brinden algún beneficio.
El objetivo perseguido será que sean puestas en marcha y comiencen a producir retorno de inversión, lo cual, en metodologías predictivas (aquellas con definición y planeamiento exhaustivos al inicio), recién comenzaría a aparecer con el paquete completo funcionando.
Todo bien hasta aquí, pero con un detalle. Si esto ocurre, o se generan nuevos equipos para que atiendan el mantenimiento de lo que se puso a funcionar, o se baja la disponibilidad de recursos para la próxima iteración o período constructivo.
Lo más lógico en estos ambientes es que los mismos equipos trabajen en la remediación de problemas ya que son quienes conocen más sobre cómo están hechas las cosas.
Por otro lado, como los recursos humanos preparados son limitados en casi todos los mercados, es imposible armar nuevos equipos de manera rápida y eficiente, esto sin tener en cuenta el aumento de los costos de producción.
A más funciones liberadas, más bugs o tickets con problemas y más horas asignadas a mantenimiento, con lo que la curva de velocidad de producción de los equipos es descendente no por trabajar mal, sino por tener que excluir horas disponibles para atender los problemas operativos.
También es importante el universo de usuarios a los que se libera la aplicación o las funciones de la aplicación, ya que a más usuarios, más pruebas y circuitos recorridos por ellos, y por supuesto, más críticas serán las fallas por el volumen de transacciones.
Si esto no es resuelto con mediana rapidez, el resultado es contraproducente, los usuarios se cansan, descreen de la solución, dudan de lo que se les entrega, aumenta el pesimismo y disminuye la motivación.
Resultado: Un mal negocio para todos.
¿Es culpa del marco de trabajo ágil? Definitivamente NO.
Es culpa del mal uso del mismo, del mal criterio en la selección de los elementos que se pueden liberar y de cuales deben quedar relegadas en un laboratorio con un universo pequeño de clientes en prueba y sin entregar al usuario de negocio, al menos en lo que a producción se refiere, hasta que estén exhaustivamente probadas.
Como cualquier otro medio o recurso, el marco ágil no solamente hay que usarlo bien en la forma, sino usar también, y mucho, el sentido común para saber hasta dónde correr riesgos.
¿Esto no pasa con metodologías predictivas como PMI o Prince2?
Por supuesto que sí, pero de distinta manera.
Cuando el paquete se libera, gran parte del equipo se libera. La criticidad de los problemas que aparecen es la misma, pero con agravantes: sucede todo junto tras la liberación y se suma la distancia o diferencia que puede existir entre lo que se pidió al inicio, con lo que se necesita al momento de la entrega.
Usualmente (sin decir que esto esté bien, solo sucede), no se considera necesario un gran equipo para el mantenimiento, y los recursos a liberar son asignados con antelación a otros proyectos.
Entonces, ante los requerimientos que se acumulan, comienza la lucha para recuperar los recursos humanos originales para un proyecto que. supuestamente, estaba terminado y entregado.
Volviendo al inicio, ser ágil es una forma de encarar la tarea y no el objetivo de una organización o parte de ella, y por supuesto, su elección como marco a aplicar depende de lo que tengamos que hacer.
Una organización debe tener en claro para qué quiere ser ágil, ya que si no lo sabe y toma la agilidad como un fin, con seguridad y definitivamente, solo terminará acelerando el desastre…