Ágil y Rápido no es lo mismo

No se puede negar que cada día se les exige mayor velocidad a los negocios, en todo. Velocidad para producir productos y servicios, velocidad para resolver inquietudes de los clientes, velocidad para satisfacer la demanda, atender los empleados.  Velocidad para todo.

Los proyectos, es mas, los productos de los proyectos, la razón por la cual estamos emprendiendo un proyecto, no son ajenos a esta necesidad de velocidad.  Las metodologías tradicionales para atender proyectos son bastante robustas, requieren de muchas actividades y pasos que hacen suponer que las cosas van más lentas de lo que uno quisiera.

No se escapa ninguna, ni PMBok, ni PRINCE2 ni ISO21500.  Tanto así, que las versiones recientes han incorporado temas “agiles” dentro de la definición de sus enfoques para tratar de atender los requerimientos que priman hoy sobre la generación de proyectos y la obtención de los productos de estos con mayor velocidad a lo que tradicionalmente se obtiene.

Se suman insatisfacciones con la gestión de proyectos como la extensión en tiempos y costos, la obtención de productos sin todos los requerimientos funcionales, la desbandada de los líderes de proyectos, la desconexión con los responsables de poner el producto del proyecto a generar el beneficio esperado.  Todo porque se “pierde el impulso”, ese “factor wow” con el que inicia el proyecto, y en el día a día se va desvaneciendo el entusiasmo.

Aparecen entonces las metodologías ágiles, mal entendidas, por la extensión de su nombre, como si fueran más rápidas que las otras.  Son igual de complejas, requieren trabajo similar a las otras para terminar un proyecto, sin embargo, se enfoca en pequeñas entregas parciales que permiten ir obteniendo resultados en la medida que va avanzando el proyecto.

Algunos detractores indican que esto no es nada distinto a tener un gran proyecto, pero definido por fases. Y ahí radica lo que consideramos es la mayor equivocación.  Manejar proyectos de forma “ágil” implica un cambio en toda su concepción, desde las restricciones hasta lo que se espera obtener; desde el detalle de la definición de requerimientos hasta manejo de la posibilidad de que todo el proyecto nunca se termine.

Ojo que no estamos diciendo que el proyecto se maneje de manera más fácil, ni que sea más rápido.  Es más, somos partidarios que solo un 20% aproximadamente de los proyectos de una empresa requieren utilizar estas metodologías robustas.

Hay mucha teoría disponible sobre las metodologías ágiles, por lo que no pretendemos que este escrito las describa.  Haremos énfasis en los puntos de la “filosofía ágil” que consideramos críticos a atender en caso de que esté contemplando usarlas, y que pueden servir no solo para unos pocos proyectos grandes, sino para todo lo que estructure como proyecto en su empresa.

Resultado Incierto

Si usted conoce cual es el resultado de lo que va a obtener, entonces no se ponga a ensayar con metodologías ágiles. Hay otras muchas que le permiten avanzar hacia ese resultado.  Construir un edificio, hacer un programa de software para algo que es claro como una nomina o una contabilidad, hasta lanzar un cohete a la luna. Todos estos resultados son ciertos, se conoce cómo se debe llegar a ellos, y no necesitan de metodologías ágiles.

Cuando el resultado es incierto, cuando en realidad no conocemos exactamente como debe ser lo que estamos buscando, como en proyectos de innovación, es ahí donde la flexibilidad que ofrece la filosofía ágil, de partir el proyecto en pequeños entregables o “mínimos productos viables”, que permite tener un objetivo corto en plazo y en presupuesto, y ver qué tanto logramos hacer con eso.

Es más, durante ese impulso, es probable que, a través de la observación y el avance, nos demos cuenta de que hay que cambiar el objetivo, que el resultado puede ser mejor de otra manera.  Libertades que no nos dan las metodologías tradicionales.

El Equipo y no la Tecnología

La filosofía ágil pone énfasis en el trabajo mancomunado de un equipo de personas con haberes y saberes complementarios, donde la opinión de cada uno es valiosa por si misma, y el empoderamiento para tomar decisiones hacia el avance del objetivo es completo.

Este enfoque permite la toma de decisiones con mayor agilidad y tiempo de respuesta, e inclusive hasta cambiar el entregable en aras de una mejor versión que ni siquiera se pensó desde el comienzo.

La metodología tradicional tiene estructuras de toma de decisiones que son más rígidas, precisamente por la experticia que se tiene tanto en el qué como en el cómo.  Hacer cambios a métodos ya probados que funcionan está inclusive desmotivado en estas metodologías, y de ahí que haya comités de control de cambios y control de alcance.

Si no puede empoderar un equipo para que trabaje dentro de las libertades que da la filosofía ágil, es mejor que se ciña a la filosofía tradicional, o no emprenda el proyecto del todo.

No se olvide del resultado

En cualquiera de las dos vías que decida emprender, el resultado termina siendo en ultimas lo que debe regir las decisiones.   Usando una metodología ágil, está claro que está definido un presupuesto y un tiempo (lo que marca cada sprint), y se estima o que se puede lograr.   En la metodología tradicional, está claramente estipulado lo que se desea tener, y se estima el costo y el tiempo requerido para lograrlo.

Esto hace que, en la metodología ágil, algunos perciban que hay un menor riesgo, precisamente sobre las dos variables que en la metodología tradicional se estiman, con bajos niveles de certeza y exactitud, extendiendo tiempos y presupuestos sin todavía ver un resultado.

En un proyecto de innovación, usando la filosofía ágil, es muy fácil verificar durante el transcurso de cada sprint, que se avance hacia los objetivos planteados. Y también es más fácil identificar el momento de parar un proceso que no se ve que conduce a un resultado concreto, sin haber invertido grandes sumas de dinero.

Antes de arrancar, y de subirse al bus de lo ágil, revise si realmente su proyecto cumple con las características necesarias para abordarlo de esa manera.  De lo contrario, sería otro proyecto más en la lista de esos que se terminan por abandono.