• Daniel Sachi

Agilidad ¿Medio o fin?

Actualizado: ago 27


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, 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.

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 la metodología, la desacreditan y la 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 de la metodología? Definitivamente NO.

Es culpa del mal uso de la misma, 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, la metodología ágil no solamente hay que usarla 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 metodología 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…


#SCRUM #Kanban #leanprocess #TQM #metodologíaspredictivas #metodologíaságiles #disponibilidadderecursos #periodoconstructivo #criteriodeselección #PMI #Prince2 #cambiodeparadigma

Argentina     //  Tel: +54 11 4736 4367 / +54 911 3219-3259

Bolivia          //  Tel: +59 1 6848 3033 / 79324524

Guatemala   //  Tel: +50 2 4014 2257

roi_logoweb_blanco_1.png
  • LinkedIn Social Icon
  • Facebook Social Icon
  • Twitter Social Icon
  • Blanco Icono de YouTube

E-mail          //   info@riskout-intl.com

creative_logoweb_blanco.png

Miembro

fundador de

© 2020 por ROI AGILE INTERNATIONAL - Todos los derechos reservados.